Với sự phát triển của công nghệ, các ECU liên quan đến nhiều chức năng khác nhau như điều khiển, vận hành, và viễn thông đã được phát triển, kéo theo sự gia tăng về số lượng và độ phức tạp của phần mềm liên quan. Sự gia tăng độ phức tạp này đã dẫn đến những tác dụng phụ như sự kém hiệu quả trong phân công lao động giữa các nhà sản xuất ô tô và các nhà cung cấp linh kiện, cũng như việc trì hoãn phát triển.
Trung bình, mỗi chiếc xe trong tập đoàn Volkswagen được trang bị khoảng 70 ECU và 3-5 hệ thống BUS, được cung cấp bởi khoảng 200 công ty phần mềm. Vấn đề là kiến trúc phần mềm (SW Architecture) khác nhau giữa các nhà cung cấp và các linh kiện, dẫn đến việc phải chi 200 triệu euro hàng năm để điều phối và tích hợp phần mềm. Không chỉ dừng lại ở chi phí khổng lồ, quá trình tích hợp hệ thống trước khi bắt đầu sản xuất xe còn gặp phải tới 10.000 lỗi phần mềm, trở thành một trở ngại lớn cho việc ra mắt xe mới.
Do sự gia tăng độ phức tạp này, nhu cầu chuẩn hóa kiến trúc phần mềm (SW Architecture) để quản lý hiệu quả hơn đã tăng lên. Điều này dẫn đến sự cần thiết của một nền tảng phần mềm nhúng (Embedded SW Platform) giúp các nhà sản xuất ô tô và các nhà cung cấp linh kiện có thể phát triển và sản xuất các mô-đun ECU đa dạng có thể tương tác với nhau.
Chuẩn Hóa Thông Qua Autosar
Trước tình hình đó, dưới sự dẫn dắt của các nhà sản xuất ô tô hàng đầu châu Âu, tiêu chuẩn phần mềm ô tô mở AUTOSAR đã được ra mắt vào năm 2003. AUTOSAR (Automotive Open System Architecture) là giải pháp nhằm giải quyết sự phức tạp của phần mềm trên xe bằng cách chuẩn hóa kiến trúc tham chiếu (Reference Architecture) cho phần mềm ECU.
Autosar đã được Ra Mắt Vào Năm 2003
AUTOSAR hiện có sự tham gia của 9 Core Partner, 1 Strategic Partner, cùng với 60 Premium Partner và 60 Development Partner.
Lý do chính mà các nhà sản xuất ô tô và các nhà cung cấp linh kiện toàn cầu áp dụng AUTOSAR là nhằm tách biệt phần cứng (HW) và phần mềm (SW) bằng cách thiết kế phần mềm ứng dụng (Application SW) và phần mềm cơ bản (Basic SW) dưới khái niệm thành phần (Component). Điều này giúp tăng khả năng tái sử dụng phần mềm nhúng cho ô tô, từ đó nâng cao hiệu quả trong việc phát triển và sử dụng phần mềm.
Việc áp dụng tiêu chuẩn này giúp các nhà sản xuất ô tô giảm bớt các quy trình phức tạp và thời gian cần thiết để tích hợp và kiểm chứng phần mềm khác nhau từ nhiều nhà cung cấp linh kiện. Ngoài ra, nó còn giúp giảm chi phí phát triển và cải thiện tính kịp thời trong việc phát triển các mẫu xe mới.
Autosar Classic Và Autosar Adaptive
Adaptive AUTOSAR
Với sự phát triển của các công nghệ như điện khí hóa và tự hành, các bộ vi xử lý hiệu suất cao đã bắt đầu được sử dụng trong ô tô để triển khai các công nghệ an toàn và tiện nghi đa dạng. Hơn nữa, để đáp ứng với trải nghiệm người dùng mới và đa dạng, các dịch vụ sử dụng truyền thông đám mây và hệ thống Back End, cũng như việc cập nhật phần mềm (SW), đã trở nên quan trọng.
Adaptive Autosar Và Autosar Classic
Tuy nhiên, phần mềm AUTOSAR truyền thống tập trung vào phần kiểm soát xe đòi hỏi khả năng phản hồi thời gian thực cao và có cấu trúc phân bổ tài nguyên phần cứng (HW) một cách tĩnh (các chức năng phụ tương tác được cố định). Do đó, nó được thiết kế theo cách khó cập nhật phần mềm (SW) mà không cần thay thế phần mềm trung gian (Middleware). Điều này đã làm tăng nhu cầu về một tiêu chuẩn mới.
Vào năm 2017, 14 năm sau khi AUTOSAR ra mắt, phiên bản tiếp theo được gọi là Adaptive AUTOSAR đã được công bố. Adaptive AUTOSAR có khả năng sử dụng hệ điều hành dựa trên POSIX (Portable Operating System Interface). Khác với Classic AUTOSAR, vốn tập trung vào MCU, Adaptive hỗ trợ các AP (Application Processor) có khả năng xử lý tính toán vượt trội như Memory Management Unit và Multi-core Processors. Do đó, việc cập nhật phần mềm (SW) và phần cứng (FW) qua mạng (OTA) cũng trở nên khả thi.
Adaptive AUTOSAR không phải là một viễn cảnh xa vời. Trên chiếc xe điện ID3 do Volkswagen ra mắt, AUTOSAR Adaptive được sử dụng làm hệ điều hành tiêu chuẩn trên In-car Application Server 1.
IOC là viết tắt của Inter OS-Application Communication. Trong AUTOSAR, có 3 phương pháp truyền thông tin như sau, và IOC là phương thức truyền thông tin giữa các OS-Application do hệ điều hành thực hiện. Nó đặc biệt đảm nhận việc giao tiếp vượt qua Core hoặc Memory Protection Boundary. Chức năng nội bộ của nó liên quan mật thiết đến hệ điều hành.
[SWS_Os_00671] Việc triển khai IOC phải là một phần của Hệ điều hành
※ Phương Pháp Truyền Thông Tin
1. Intra OS-Application communication: Bên trong RTE
2. Inter ECU communication: Phương thức dựa trên COM
3. Inter OS-Application communication (IOC): Phương thức do hệ điều hành thực hiện
Memory Protection là một đặc tính của OS-Application, và để vượt qua nó, cần có một cơ chế truyền thông đặc biệt. Hệ thống Multi-Core có thể cần thêm biện pháp để đảm bảo giao tiếp an toàn giữa các Core.
Tất cả các thành phần phần mềm AUTOSAR phải thuộc một OS-Application, nhưng không nhất thiết phải thuộc cùng một OS-Application. BSW dự kiến sẽ là Trusted Code, nhưng phải được xác định bởi một hoặc nhiều OS-Application.
IOC cung cấp dịch vụ truyền thông giữa các OS-Application, đặc biệt là qua các ranh giới cốt lõi của hệ thống Multi-Core. Truyền thông Cross-Core luôn là truyền thông giữa các OS-Application, vì vậy nó liên quan đến hai cơ chế. Tuy nhiên, truyền thông giữa các OS-Application không nhất thiết phải cần truyền thông Cross-Core.
Thông thường, truyền thông giữa các OS-Application được dự đoán sẽ thường xuyên hơn so với truyền thông ECU. Tất nhiên, điều này áp dụng cho các trường hợp liên quan chặt chẽ. Các thành phần phần mềm liên quan mật thiết và các thực thể có thể thực thi được phân phối trên hai hoặc nhiều Core để cải thiện hiệu suất hệ thống. Nếu các tệp thực thi được thiết kế để chạy trên một Core đơn lẻ được phân phối trên nhiều Core, thì việc đáp ứng các ràng buộc thời gian sẽ trở nên khó khăn hơn.
Trong hệ thống chỉ có một Core, IOC có thể không được sử dụng hoàn toàn nếu chỉ có một OS-Application hoặc OS-Application không sử dụng cơ chế Memory Protection.
Mục Đích Sử Dụng
• Truyền thông giữa các Application được bảo vệ bằng Memory.
• Hỗ trợ Multi-Core để thực hiện trao đổi thông tin giữa các Core.
Autosar Os Hệ Điều Hành – Ioc
IOC cung cấp cho khách hàng dịch vụ truyền thông có thể giao tiếp vượt qua OS-Application Boundary trong cùng một ECU. RTE sử dụng dịch vụ IOC để giao tiếp qua những Boundary này. Mọi truyền thông phải được định tuyến qua RTE ở cả phía truyền tin (hoặc client) và nhận tin (hoặc server).
Các client ngoài RTE hiện không được hỗ trợ truy cập trực tiếp vào dịch vụ IOC. Tuy nhiên, nếu client (ví dụ, CDD) tự viết hoặc cung cấp một IOC Configuration Description mới và cung cấp Callback function cụ thể nếu cần thiết, điều này có thể thực hiện được.
Các thành phần phần mềm hoặc mô-đun BSW trong cùng một OS-Application (do đó tồn tại trên cùng một Core) không nên gọi dịch vụ IOC để giao tiếp. Tuy nhiên, nếu IOC hỗ trợ truyền thông N:1 và không phải tất cả người gửi và người nhận đều nằm trong cùng một OS-Application, thì phải sử dụng IOC.
Để duy trì tính độc lập với phần cứng của RTE, tất cả các OS-Application và các cơ chế truyền thông nội bộ được đóng gói trong IOC. Chức năng nội bộ của IOC phụ thuộc vào các thuộc tính kiến trúc phần cứng, đặc biệt là kiến trúc bộ nhớ.
IOC phải đảm bảo tính nhất quán của dữ liệu trong giao tiếp giữa các OS-Application hoặc các Core. Điều này đặc biệt có nghĩa:
• Thứ tự tuần tự của các hoạt động giao tiếp trong Queue Communication không thay đổi. Trong trường hợp truyền thông N:1, thứ tự tin nhắn từ các nguồn khác nhau là thuộc tính triển khai.
• Nội dung của tất cả dữ liệu được truyền trong một lần truyền thông không bị thay đổi. Mỗi hoạt động truyền thông được thực hiện như một hoạt động Atomic.
Chức Năng IOC
• Hỗ trợ truyền thông 1:1, N:1, N
.
• Data item được tạo thành từ một khối bộ nhớ duy nhất, dù là atomic hay cấu trúc phức tạp.
• Gửi nhiều data item cùng một lúc chỉ có thể thực hiện trong 1:1.
• Hỗ trợ cả Unqueued và Queued (trường hợp Queued cần phải định nghĩa IOC Queue Length).
• Một hoạt động truyền thông được xác định bởi Sender, Receiver, Data Type, Notification, và Queuing.
IOC chỉ cung cấp truyền thông Sender-Receiver. RTE chuyển đổi các cuộc gọi Client-Server và việc truyền phản hồi thành truyền thông Sender-Receiver. Hỗ trợ truyền thông 1:1, N:1, N
.
Với IOC, một data item có thể được truyền cho mỗi hoạt động truyền thông Atomic. Data item có thể là giá trị của một kiểu dữ liệu nguyên thủy Atomic hoặc là tham chiếu đến một cấu trúc dữ liệu phức tạp. Tuy nhiên, cấu trúc dữ liệu phải được triển khai dưới dạng một khối bộ nhớ duy nhất để có thể truyền dưới dạng một phần duy nhất. IOC không cần biết cấu trúc dữ liệu nội bộ; chỉ cần biết địa chỉ bộ nhớ cơ bản và độ dài.
Gửi nhiều data item cùng một lúc chỉ có thể thực hiện trong 1:1. Trong trường hợp này, chức năng IOC phải sử dụng nhiều kiểu dữ liệu và địa chỉ bộ nhớ khác nhau. Ưu điểm so với việc gọi IOC tuần tự là cơ chế mở Memory Protection Boundary và thông báo cho người nhận chỉ cần thực hiện một lần. Ngoài ra, tất cả các data item được truyền như một hoạt động Atomic duy nhất, đảm bảo tính nhất quán.
IOC hỗ trợ cả Unqueued (Last-is-Best, ý nghĩa dữ liệu) và Queued (FIFO, ý nghĩa sự kiện). Nếu là Queued, cần phải định nghĩa IOC Queue Length.
Mỗi hoạt động truyền thông Atomic được xác định riêng trong Configuration Description liên quan đến Sender, Receiver, Data Type, Notification, và Queuing.
Giao Diện IOC
1. Cung cấp giao diện thay vì cung cấp Generic API.
2. Send Service ghi dữ liệu vào bộ nhớ chia sẻ với Receiver, và Receiver sẽ đọc dữ liệu từ bộ nhớ chia sẻ đó.
3. Với Notification, IOC có thể sử dụng Callback function do người dùng tạo để thông báo cho Receiver khi có dữ liệu có thể đọc được, tùy chọn.
Truyền Thông
Mỗi lần truyền dữ liệu cần tạo một dịch vụ IOC duy nhất, xác định Sender, Receiver, Data Type, Notification, và Queuing. Giao diện giữa RTE và IOC phải tương tự với giao diện giữa các thành phần phần mềm và RTE. Thay vì cung cấp một Generic API, tạo một giao diện cụ thể cho mỗi hoạt động truyền thông.
Hỗ trợ các phương pháp tối ưu hóa tốt hơn nhiều so với Generic API (như hàm inline hoặc macro). Hầu hết các tối ưu hóa này có thể được thực hiện ngoại tuyến khi tạo mã, thay vì tiêu thụ tài nguyên thời gian thực quý giá.
Đối với mỗi truyền thông dữ liệu được chỉ định trong IOC Configuration Description, có một tập hợp IOC service API duy nhất. Mỗi service API được tạo và có thể được nhận dạng bởi unique ID cho mỗi truyền thông dữ liệu. Trong trường hợp truyền thông N:1, mỗi người gửi phải sử dụng API của riêng mình.
Cùng một IOC service API và do đó cùng một truyền thông 1:1 có thể được sử dụng bởi nhiều thực thể có thể thực thi trong cùng một SWC ở cả phía người gửi và người nhận. Tuy nhiên, chức năng IOC không thể tái nhập. Nếu IOC sử dụng spin lock trong hệ thống multi-core, có thể xảy ra lỗi spin lock. Do đó, cùng một IOC API phải được gọi tuần tự.
Miễn là tất cả các thực thể có thể thực thi được lên lịch trong cùng một Task, sẽ không có vấn đề. Nếu không, người gọi phải chịu trách nhiệm đảm bảo rằng cùng một IOC API không được gọi lại trước khi kết thúc cuộc gọi khác.
Các thành phần phần mềm chỉ có thể truy cập IOC thông qua RTE. Chỉ có RTE mới quyết định sử dụng dịch vụ truyền thông nào để hỗ trợ các yêu cầu truyền thông của các thành phần phần mềm. Truy cập trực tiếp vào dịch vụ IOC bởi mô-đun BSW không được hỗ trợ, nhưng trong trường hợp không thể tránh khỏi, nó có thể được cho phép đối với CDD và các mô-đun khác.
Client phải tự viết hoặc cung cấp IOC Configuration Description được chỉ định. Đối với Receiver Notification, client phải chỉ định và cung cấp Callback function cụ thể. Tuy nhiên, IOC chỉ hỗ trợ truyền thông Sender-Receiver.
Notification
IOC có thể tùy chọn thông báo cho Receiver ngay khi dữ liệu được truyền có thể truy cập được ở phía nhận bằng cách gọi Callback function đã cấu hình do người dùng cung cấp.
Một cách triển khai khả thi là kích hoạt cơ chế Interrupt (CAT 2) để gọi Callback function từ phía ISR của Receiver hoặc sử dụng bẫy (trap) do MCU cung cấp. Vì Callback function được gọi trong ISR, nó phải hiệu quả và gọn nhẹ.
Trong một số trường hợp cụ thể, không cần kích hoạt ISR để thông báo cho Receiver. Sau đó, IOC Generator có thể chọn phương pháp IOC Notification nội bộ phù hợp dựa trên kiến trúc phần cứng và các ràng buộc khác. Điều này có thể hiệu quả hơn ISR đối với truyền thông giữa các OS-Application trong cùng một Core.
Notification có thể được xử lý hoàn toàn bởi client của IOC. RTE gọi chức năng truyền IOC và sau đó thông báo cho RTE phía Receiver rằng dữ liệu mới đã sẵn sàng trong IOC. Trong trường hợp này, IOC không bị ảnh hưởng bởi các chi tiết của cơ chế Notification.
Nếu giải pháp thay thế này chứng minh là hiệu quả hơn, IOC Notification nội bộ có thể bị loại bỏ trong các bản phát hành AUTOSAR tương lai.
IOC với Notification
1. Trong Core0 của SWC (Software Component), gọi Rte_Call__(…, ).
2. Lệnh Rte_Call trên được ánh xạ thành IocSend_ ().
3. RTE buffer được sao chép vào IOC buffer (lưu trong bộ nhớ chia sẻ giữa sender và receiver).
4. Hàm Rte_Call sử dụng lệnh gọi hệ điều hành để kích hoạt Task (= notification).
5. Nhận dữ liệu qua IocReceive và server runnable.
Ví dụ về Notification
SWC nhận dữ liệu thông qua RTE và kích hoạt Task để thực hiện Notification. Nếu không có Notification, bên nhận sẽ hoạt động bằng cách kiểm tra Buffer thông qua Task định kỳ
(Điểm (1), (2), (3), (4), (5) trong văn bản khác với ①, ②, ③, ④, ⑤ trong hình).
Trong hệ thống Real-time, lỗi thời gian xảy ra khi Task hoặc Interrupt không đạt được Deadline trong quá trình thực thi. Tuy nhiên, AUTOSAR OS không cung cấp Deadline Monitoring cho việc bảo vệ thời gian. Deadline Monitoring không đủ để xác định chính xác Task / ISR gây lỗi thời gian trong hệ thống AUTOSAR.
Task / ISR không liên quan có thể gây ra lỗi thời gian bằng cách cản trở hoặc chặn Task / ISR đang thực thi quá lâu. Trong trường hợp này, nguyên nhân của lỗi hệ thống là từ Task / ISR không liên quan, và lỗi thời gian được phát hiện khi Task / ISR đang chạy không đạt được Deadline. Do đó, Task / ISR không đạt Deadline không nhất thiết là nguyên nhân của lỗi đang chạy; đó chỉ là điểm phát hiện lỗi thời gian nhanh nhất.
Nguyên nhân
Lỗi thời gian xảy ra trong hệ thống Real-time khi Task hoặc ISR không đạt được Deadline.
→ Insufficient (Không đủ)!!
→ Deadline không đạt được của TASK/ISR không phải lúc nào cũng là nguyên nhân của vấn đề!!
Deadline Monitoring cho các Task không đạt Deadline có thể dẫn đến việc sử dụng chứng cứ lỗi không chính xác. Vấn đề được giải thích rõ hơn qua hình ảnh dưới đây.
Xem xét cấu hình của hệ thống sau:
Nếu tất cả các Task đã sẵn sàng thực thi vào thời điểm 0, bạn có thể dự đoán Task tiếp theo sẽ được thực thi và đảm bảo rằng tất cả các Task có thể đạt được Deadline.
Bảo Vệ Thời Gian (timing Protection) – Autosar Os
Xem xét Trường hợp Task A và Task B hoạt động không chính xác
Khi Task A và Task B hoạt động không đúng cách, ta có thể nhận thấy rằng:
Task A và Task B đang thực thi lâu hơn thời gian quy định và Task B đến sớm hơn 2 Tick so với thời gian quy định. Dù Task A và Task B đều đáp ứng được Deadline, nhưng Task C không thể đáp ứng Deadline do sự chậm trễ của Task A và Task B. Đây là hiện tượng Fault Propagation.
Fault Propagation xảy ra khi lỗi từ các phần không liên quan trực tiếp gây ra lỗi trong các phần hệ thống hoạt động đúng.
Fault Propagation
Các loại Timing Fault được định nghĩa trong AUTOSAR
Trong hệ điều hành AUTOSAR OS, việc liệu Task hoặc ISR có đáp ứng được Deadline trong một hệ điều hành Fixed Priority Preemptive OS như thế nào được xác định bởi các yếu tố sau:
1. Thời gian thực thi của Task / ISR trong hệ thống
2. Thời gian chặn khi Task / ISR chiếm tài nguyên chia sẻ hoặc vô hiệu hóa ngắt
3. Khoảng cách giữa các Task / ISR trong hệ thống
AUTOSAR OS kiểm soát các yếu tố này trong môi trường runtime để đảm bảo Timing Protection an toàn và chính xác. Hệ thống cũng thực hiện xử lý lỗi khi xảy ra Timing Fault để đảm bảo hoạt động đúng thời gian.
1. Execution Budget
• Đảm bảo một mức trên cố định gọi là Execution Budget cho thời gian thực thi của Task / ISR (CAT 2) để ngăn chặn lỗi thời gian (Execution Time Protection).
o Khi thời gian thực thi của Task / ISR (CAT 2) vượt quá giới hạn Execution Budget, lỗi sẽ xảy ra.
o Gọi ProtectionHook(E_OS_PROTECTION_TIME).
2. Lock Budget
• Đảm bảo một mức trên cố định gọi là Lock Budget cho thời gian khóa của Task / ISR (CAT 2) để ngăn chặn lỗi thời gian (Locking Time Protection).
o Khi thời gian chặn của Task / ISR (CAT 2) do khóa tài nguyên chia sẻ / vô hiệu hóa ngắt vượt quá giới hạn Lock Budget, lỗi sẽ xảy ra.
o Gọi ProtectionHook(E_OS_PROTECTION_LOCKED).
3. Time Frame
• AUTOSAR OS bảo đảm một thời gian tối thiểu gọi là Time Frame để ngăn chặn lỗi thời gian (Inter-Arrival Time Protection).
o Khi Inter Arrival Time giữa các Task / ISR ngắn hơn Time Frame (tức là quá thường xuyên kích hoạt), lỗi sẽ xảy ra.
o Gọi ProtectionHook(E_OS_PROTECTION_ARRIVAL).
o Phát hiện các ngắt xảy ra quá thường xuyên so với dự đoán.
o Phát hiện các Task / ISR không khớp với chu kỳ thiết kế.
AUTOSAR OS là một hệ điều hành tiêu chuẩn quốc tế cho các hệ thống điện tử trong xe hơi, dựa trên phiên bản 2.23 của OSEK/VDX OS. Hệ điều hành này mở rộng 11 chức năng từ phiên bản cơ bản, bao gồm các tính năng bảo vệ hệ thống, lập lịch thời gian thực, và xử lý bộ đếm.
Đặc điểm của OS-Application
AUTOSAR OS hỗ trợ một tập hợp các đối tượng hệ điều hành (như Task, ISR, Alarm, Schedule Table, Counter) cấu thành Functional Unit. Tập hợp các đối tượng này được gọi là OS-Application.
• OS-Application sẽ yêu cầu các tài nguyên xử lý của bộ vi xử lý được đặt riêng giữa các OS-Application chia sẻ. Tất cả các đối tượng hệ điều hành (Task, ISR, Counter, Alarm, Schedule Table, v.v.) phải thuộc cùng một OS-Application khi được sử dụng.
• Tất cả các đối tượng thuộc cùng một OS-Application có thể truy cập lẫn nhau. Quyền truy cập tới các đối tượng từ một OS-Application khác có thể được cấp trong cấu hình. Nếu một Task có thể thiết lập sự kiện, nó cũng có thể truy cập vào sự kiện đó. Quyền truy cập có nghĩa là các đối tượng hệ điều hành này được phép như các tham số cho dịch vụ API.
• Resource không thuộc về bất kỳ OS-Application nào nhưng phải được cấp quyền truy cập rõ ràng.
• Một đối tượng OS-Application phải nằm trên cùng một Core.
Các loại OS-Application
1. Trusted OS-Application
o Trusted OS-Application có thể tắt các chức năng Monitoring hoặc Protection trong thời gian runtime. Nó có thể truy cập vào bộ nhớ và API của mô-đun hệ điều hành mà không bị hạn chế và có thể hoạt động trong chế độ Privileged Mode nếu bộ vi xử lý hỗ trợ.
o Có thể hoạt động mà không bị giám sát hoặc bảo vệ.
o Có quyền truy cập không giới hạn vào bộ nhớ và API của mô-đun hệ điều hành.
2. Non-Trusted OS-Application
o Non-Trusted OS-Application không thể tắt các chức năng Monitoring hoặc Protection trong thời gian runtime. Quyền truy cập vào bộ nhớ và API của mô-đun hệ điều hành bị hạn chế và nó phải tuân thủ các hoạt động thời gian trong runtime. Nếu bộ vi xử lý hỗ trợ, nó không thể hoạt động trong chế độ Privileged Mode.
o Hoạt động trong chế độ Non-Privileged.
o Quyền truy cập hạn chế vào API và tài nguyên phần cứng.
Dịch vụ của AUTOSAR OS
AUTOSAR OS cung cấp dịch vụ để cung cấp thông tin về quyền truy cập và thành viên của đối tượng cho người gửi. Các dịch vụ này được sử dụng để gọi giữa các OS-Application để kiểm tra quyền truy cập và các tham số.
• Resource không thuộc về bất kỳ OS-Application nào nhưng quyền truy cập cần được cấp rõ ràng. Nguyên lý tương tự cũng áp dụng cho các spin lock trong hệ thống đa nhân.
• OS-Application đang chạy được xác định là OS-Application của Task hoặc ISR đang chạy. Đối với Hook Routine, OS-Application của Task hoặc ISR gọi hook được xác định là OS-Application đang chạy.
Os-application Trong Autosar Os
Trạng thái của OS-Application
OS-Application có các trạng thái xác định phạm vi truy cập đối tượng hệ điều hành từ các OS-Application khác. Mỗi OS-Application luôn ở trong một trong các trạng thái sau:
1. APPLICATION_ACCESSIBLE
o Trạng thái cho phép truy cập vào các đối tượng Application.
o Đây là trạng thái mặc định khi hệ điều hành bắt đầu.
2. APPLICATION_RESTARTING
o Trạng thái không cho phép truy cập vào các đối tượng Application.
o Có thể thay đổi trạng thái thành APPLICATION_ACCESSIBLE bằng cách sử dụng hàm AllowAccess().
3. APPLICATION_TERMINATED
o Trạng thái khi Application đã kết thúc và không còn sử dụng được.
Trạng Thái Của Os-application
Quyền truy cập giữa các OS-Application
• Các đối tượng thuộc cùng một OS-Application có thể truy cập lẫn nhau mà không cần thiết lập quyền truy cập thêm.
• Truy cập vào các đối tượng của OS-Application khác cần phải được cấu hình cụ thể.
• Đối với mỗi đối tượng, bạn có thể cấu hình OS-Application nào có thể truy cập vào nó.
Quyền Truy Cập Giữa Các Os-application
Các API chính liên quan đến quyền truy cập OS-Application
1. ApplicationType CheckObjectOwnership(ObjectTypeType <ObjectType>, ObjectID <ID>)
o Kiểm tra OS-Application nào sở hữu đối tượng cụ thể.
2. ApplicationType CheckObjectAccess (ApplicationType AppID, ObjectTypeType <ObjectType>, ObjectID <ID>)
o Kiểm tra xem OS-Application có quyền truy cập vào đối tượng cụ thể hay không.
Các API chính liên quan đến trạng thái OS-Application
1. StatusType GetApplicationState(ApplicationType <ApplicationID>, ApplicationStateRefType Value)
o Sử dụng để kiểm tra trạng thái hiện tại của OS-Application.
2. StatusType TerminateApplication(ApplicationType ApplicationID, RestartOption)
o Kết thúc OS-Application.
o Nếu RestartOption là RESTART, trạng thái sẽ chuyển sang APPLICATION_RESTARTING.
o Nếu RestartOption là NO_RESTART, trạng thái sẽ chuyển sang APPLICATION_TERMINATED.
3. StatusType AllowAccess(void)
o Chuyển trạng thái của OS-Application hiện tại từ APPLICATION_RESTARTING sang APPLICATION_ACCESSIBLE.
OS-Application có thể gọi Trusted Function được cung cấp bởi OS-Application khác đáng tin cậy. Để thực hiện điều này, cần phải chuyển đổi từ Privileged Mode sang Non-Privileged Mode.
Thông thường, điều này được thực hiện thông qua các bước sau:
1. Mỗi Trusted OS-Application có thể cung cấp dịch vụ mà OS-Application khác có thể gọi.
2. Các dịch vụ đáng tin cậy này phải được cấu hình để có thể được gọi bởi Non-Trusted OS-Application.
3. Việc gọi từ Non-Trusted OS-Application đến dịch vụ đáng tin cậy sử dụng cơ chế do hệ điều hành cung cấp (ví dụ: Trap hoặc Software Interrupt). Dịch vụ này được truyền cùng với một định danh được sử dụng để xác minh liệu dịch vụ có thể được gọi trong môi trường đáng tin cậy hay không.
4. Hệ điều hành cung cấp dịch vụ kiểm tra xem vùng nhớ có thể Write/Read/Execute Accessible từ OS-Application hay không. Nếu vùng nhớ là một phần của không gian stack, thông tin này cũng được trả về.
Chức Năng Chính
• Trusted OS-Application cung cấp các hàm của mình dưới dạng Trusted Function cho bên ngoài (cùng một Core).
• Non-Trusted OS-Application sử dụng CallTrustedFunction API để gọi hàm của Trusted OS-Application.
Hạn Chế Sử Dụng
Chỉ có thể sử dụng giữa các application trong cùng một Core.
Memory Protection là một dịch vụ bảo vệ để ngăn chặn các chương trình thực thi như Task/ISR truy cập trái phép vào Data, Code, và Stack Session. Memory Protection chỉ khả dụng trên các bộ xử lý cung cấp hỗ trợ phần cứng cho bảo vệ bộ nhớ.
• Code: Flash
Code Session có thể là riêng tư đối với một OS-Application hoặc được chia sẻ giữa tất cả các OS-Application (sử dụng thư viện chia sẻ). Nếu không sử dụng Code Protection, việc thực thi mã không đúng có thể dẫn đến vi phạm bộ nhớ, thời gian, hoặc dịch vụ.
• Data: Flash (const), Ram (bss, data)
OS-Application có thể có Data Session riêng tư, và Task/ISR cũng có thể có Data Session riêng tư. Data Session riêng tư của OS-Application được chia sẻ giữa tất cả các Task/ISR thuộc OS-Application đó.
• Stack: Ram
OS-Application bao gồm nhiều Task và ISR. Theo định nghĩa, stack của những đối tượng này chỉ thuộc về các đối tượng chủ sở hữu, do đó không cần chia sẻ dữ liệu stack giữa các đối tượng ngay cả khi chúng thuộc cùng một OS-Application. Memory Protection đối với stack của Task và ISR hữu ích chủ yếu vì hai lý do sau:
1. Memory Protection phát hiện các tình huống lỗi, như tràn stack (stack overflow) hoặc thiếu stack (stack underflow) cho Task hoặc ISR, nhanh chóng hơn so với việc giám sát stack (Stack Monitoring).
2. Để đáp ứng một số ràng buộc an toàn, nó cung cấp sự bảo vệ giữa các thành phần cấu thành và OS-Application.
Memory Protection
Điều Kiện và Ràng Buộc
1. Phải chọn Scalability là SC3 hoặc SC4.
2. Chỉ có thể sử dụng khi phần cứng hỗ trợ.
o Trong trường hợp Infineon AURIX, điều này được định nghĩa trong Trap Class 1 (Internal Protection Traps).
3. Chỉ bảo vệ được các đối tượng do hệ điều hành quản lý.
o Ví dụ: Không bảo vệ đối với library.
Memory Access Violation
1. Xảy ra khi chương trình thực thi (Task/ISR) truy cập vào một vùng nhớ (Code, Data, Stack) mà không có quyền.
2. Khi Memory Access Violation xảy ra, tiến hành các biện pháp xử lý:
o Gọi ProtectionHook(E_OS_PROTECTION_MEMORY).
Quyền truy cập theo loại của Application
1. Trusted OS-Application
o Có thể truy cập vào Data của các Application khác và OS Module.
2. Non-Trusted OS-Application
o Có thể truy cập vào Code và Data của chính nó.
o Không được phép ghi vào Data của các Application khác và OS Module.
o Có thể bị chặn truy cập đọc vào Data của các Application khác và OS Module.
Service (Dịch vụ) đề cập đến API của hệ điều hành. OS-Application có thể tương tác với các mô-đun của hệ điều hành thông qua Service này, và điều quan trọng là việc gọi các dịch vụ này không được làm hỏng các mô-đun của hệ điều hành.
Bảo vệ Dịch vụ giúp ngăn chặn các hư hỏng này trong quá trình runtime. Đối với các trường hợp mà OSEK không bao gồm, trạng thái lỗi của OSEK OS sẽ được áp dụng.
Trong bảng dưới đây, “C” là viết tắt của “Checked in Extended status by E_OS_CALLEVEL
Bảo Vệ Dịch Vụ – Service Protection
Ví dụ
Liên quan đến Bảo vệ Dịch vụ, có nhiều trường hợp cần xem xét. OS-Application thực hiện các cuộc gọi API.
1. Trường hợp truyền tham số không hợp lệ cho OS API
o Trả về E_OS_ID hoặc E_OS_VALUE.
2. Trường hợp gọi OS API từ ngữ cảnh không phù hợp
o Ví dụ: Gọi ActivateTask() trong StartupHook().
o Trả về E_OS_CALLEVEL.
3. Trường hợp sử dụng OS API theo cách không được định nghĩa
o Ví dụ: Task kết thúc mà không gọi TerminateTask(void) hoặc ChainTask(TaskID).
→ Trả về E_OS_MISSINGEND.
o Ví dụ: Cat2ISR kết thúc với ngắt bị khóa hoặc tài nguyên được phân bổ.
→ Trả về E_OS_DISABLEINT / E_OS_RESOURCE.
4. Trường hợp hạn chế đối với Non-Trusted OS-Application
o Ví dụ: Bỏ qua cuộc gọi ShutdownOS từ Non-Trusted OS-Application.
5. Trường hợp truy cập đối tượng thuộc về OS-Application khác
o Ví dụ: Nếu không có quyền truy cập, trả về E_OS_ACCESS.
OSEK OS đã cung cấp một số Bảo vệ Dịch vụ thông qua mã trạng thái được trả về từ các cuộc gọi dịch vụ, và đây chính là nền tảng của Bảo vệ Dịch vụ. Nói cách khác, Bảo vệ Dịch vụ chỉ được áp dụng trong trạng thái mở rộng của OSEK OS. Tuy nhiên, OSEK OS không bao gồm tất cả các trường hợp đã được mô tả ở trên. Ngoài trạng thái mở rộng bắt buộc, còn có các yêu cầu bảo vệ bổ sung có thể được áp dụng cho các trường hợp này.
Tổng quan về truyền thông AUTOSAR CAN: Layer, Kiến trúc Stack
Các Layer liên quan đến truyền và nhận CAN
• Truyền CAN Message: Application Layer → Communication Services → Communication Hardware Abstraction → Communication Driver (theo thứ tự).
• Nhận CAN Message: Communication Driver → Communication Hardware Abstraction → Communication Services → Application Layer (theo thứ tự).
Các Layer Liên Quan đến Truyền Và Nhận Can
1. Application Layer
2. Runtime Environment (RTE)
3. Communication Services
• Mô-đun AUTOSAR COM
• PDU Router
• CAN TP Protocol, J1939 Transport Protocol
• CAN SM
• NM Interface và CAN NM
• …
4. Communication Hardware Abstraction
• CAN Interface
• CAN Transceiver Driver
• Driver cho ext. CAN ASIC: Bao gồm ARISU, v.v.
5. Communication Drivers
• I/O Drivers: MCAL
• Communication Drivers
o CAN Driver: Là CAN MCAL Driver cho CAN Controller
o SPI Handler Driver
o …
6. Microcontroller
• CAN
• SPI
• …
Kiến trúc Stack CAN
AUTOSAR CAN được phân loại thành 3 chức năng chính:
• CAN Communication: Truyền và nhận thông điệp.
• CAN Status: Trạng thái truyền thông.
• CAN Network Management: Quản lý mạng.
Trước hết, AUTOSAR CAN Communication Stack được cấu thành chủ yếu bởi 5 mô-đun như sau.
Kiến Trúc Stack Can
AUTOSAR CAN Status Stack bao gồm chức năng BusOff Recovery và chức năng điều khiển Network Status.
Autosar Can Status Stack
AUTOSAR CAN Network Management bao gồm chức năng cấu hình Network và chức năng điều khiển Sleep.
Autosar Can Network Management
Lộ trình sự kiện truyền thông
Nếu vẽ lộ trình sự kiện truyền thông AUTOSAR CAN một cách dễ hiểu, nó sẽ giống như hình dưới đây.
Lộ Trình Sự Kiện Truyền Thông
Quá trình truyền thông AUTOSAR CAN (trình tự): Start, Sleep, BusOff, Recovery
Sau khi khởi tạo ban đầu (Init), BswM sẽ bắt đầu quá trình truyền thông CAN.
Trình Tự Khởi động (start Sequence)
1. SW-C truyền User ID qua RTE Client-Server và gửi yêu cầu bắt đầu truyền thông đến mô-đun ComM.
2. Mô-đun ComM nhận yêu cầu bắt đầu truyền thông và sử dụng User ID được truyền để tìm kênh nội bộ. Sau đó, yêu cầu bắt đầu truyền thông đến kênh của mô-đun CanSM đã được kết nối với ComM.
3. Trong trường hợp nền tảng có mô-đun Nm, nó sẽ yêu cầu bắt đầu truyền thông đến kênh Nm đã được kết nối.
o Thiết lập trạng thái truyền thông của CanSM thành FULL COMM.
4. Mô-đun CanSM tìm kiếm Controller ID của mô-đun CanIf đã được kết nối với kênh đó và gửi yêu cầu khởi động CAN Controller.
5. Mô-đun CanIf truyền yêu cầu khởi động CAN Controller đến CAN Driver cùng với Controller ID.
6. Sau khi xác nhận rằng việc khởi động CAN Controller đã thành công, mô-đun CanIf sẽ thông báo kết quả cho mô-đun CanSM.
7. Mô-đun CanSM truyền kết quả nhận được từ mô-đun CanIf đến mô-đun ComM.
Trình tự BusOff & Phục hồi (Recovery)
Trình Tự Busoff & Phục Hồi (recovery)
1. Khi BusOff xảy ra, CAN Driver truyền thông báo qua mô-đun CanIf đến CanSM.
2. Trong trường hợp cần thiết, có thể nhận thông báo BusOff trước khi đến CanSM thông qua CDD.
o Tuy nhiên, trong trường hợp này, để xử lý BusOff, cần phải thông báo BusOff cho CanSM.
3. Mô-đun CanSM thông báo sự cố BusOff cho các mô-đun DEM và BswM.
o DEM là Diagnostic Event Manager, ghi lại các mã chẩn đoán, v.v.
4. Mô-đun BswM và Dem có thể thông báo sự cố BusOff cho SW-C thông qua RTE.
o BswM có thể thực hiện các hành động thông qua cấu hình dựa trên quy tắc (Rule based Configuration).
o BswM có các quy tắc liên quan đến việc Shutdown.
5. Mô-đun CanSM thông báo việc chuyển sang chế độ SILENT COMM cho ComM và BswM.
o Silent COMM là trạng thái truyền thông chỉ cho phép nhận dữ liệu.
6. Mô-đun ComM thông báo việc chuyển sang chế độ SILENT COMM cho BswM.
7. Mô-đun BswM ra lệnh cho Com cấm gửi PDU.
8. Mô-đun CanSM thực hiện quy trình Bor (BusOff Recovery). Sau khi hoàn thành Bor, CanSM khởi động lại CAN Controller và thông báo chuyển sang chế độ FULL COMM cho ComM và BswM.
9. Mô-đun COM tiếp tục gửi PDU.
10. Sau khi tiếp tục gửi PDU và nếu BusOff không tái phát trong một khoảng thời gian nhất định, thông báo hoàn thành phục hồi (Recovery) sẽ được gửi đến DEM.
Trình tự xử lý Bộ đếm thời gian BusOff (Timing Flow)
1. Quá trình xử lý L1 Timer
Khi BusOff xảy ra, đợi thời gian của Bor (Bus off recovery) Timer L1.
o Nếu BusOff xảy ra trong thời gian Bor Time Tx Ensured, đợi lại Bor Timer L1 (lặp lại).
o Nếu BusOff không xảy ra trong thời gian Bor Time Tx Ensured, sẽ được xem là đã phục hồi từ BusOff.
Trình Tự Xử Lý Bộ đếm Thời Gian Busoff
2.Quá trình xử lý L2 Timer
Sau khi BusOff xảy ra, đợi thời gian của Bor (Bus off recovery) Timer L1.
• Nếu BusOff xảy ra trong thời gian Bor Time Tx Ensured và giá trị của Counter (số lần xảy ra BusOff) lớn hơn giá trị của Bor Counter, đợi lại Bor Timer L2 (lặp lại).
• Nếu BusOff không xảy ra trong thời gian Bor Time Tx Ensured, sẽ được xem là đã phục hồi từ BusOff.
Quá Trình Xử Lý L2 Timer
Thông báo liên quan đến CAN BusOff
BOR_START, BOR_COMPLETE
• BOR_START: Thông báo thời điểm xảy ra BusOff.
• BOR_COMPLETE: Thông báo thời điểm hoàn thành BusOff Recovery.
o Cũng được thông báo khi chuyển từ BUS OFF sang NO COM.
• Trong khoảng thời gian BusOff (Tx Disable), việc truyền thông điệp CAN ASW bị cấm.
Thông Báo Liên Quan đến Can Busoff
Trình tự Sleep.
Trình Tự Sleep
1 ASW gửi lệnh dừng truyền thông.
2 Mô-đun ComM gửi lệnh Network Release đến Nm Interface (NO COMM).
3 Nm Interface gửi lệnh Network Release đến mỗi Bus Nm bên dưới.
4 Các mô-đun Nm trên Bus thông báo cho Nm Interface khi mạng của chúng bước vào tạng thái SLEEP.
5 Nm Interface xác nhận rằng tất cả các Cluster đã vào trạng thái SLEEP và thông báo cho ComM.
6 Mô-đun ComM cuối cùng phê duyệt việc dừng truyền thông và gửi lệnh dừng truyền thông đến CanSM.
7 Mô-đun CanSM gửi lệnh dừng truyền thông đến CanIf.
8 CanIf gửi lệnh CAN Controller SLEEP/STOP đến MCAL Can Driver.
9 CanIf gửi lệnh CAN transceiver SLEEP/STANDBY đến CanTrcv.
• Đây là kênh Interface để thông báo khi xảy ra lỗi nghiêm trọng do OS phát hiện.
• Có định dạng hàm API.
• Có thể quyết định việc sử dụng dựa trên cấu hình.
※ Định dạng: ProtectionReturnType ProtectionHook(StatusType Fatalerror)
Mục đích Sử dụng
• Được gọi bởi OS khi xảy ra lỗi nghiêm trọng (Serious Error).
• Dựa trên loại lỗi, có thể giải quyết tình huống lỗi hoặc thực hiện system reset.
• Nội dung của hàm phải được viết bởi người dùng.
Các loại lỗi nghiêm trọng do AUTOSAR OS phân loại
(Đối với phần này, bạn cần cung cấp thông tin thêm về các loại lỗi nghiêm trọng do AUTOSAR OS phân loại để hoàn thiện bản dịch.)
Protection Hook
Xử lý khi xảy ra lỗi nghiêm trọng
• Khi một lỗi đã được định nghĩa xảy ra, cơ chế xử lý lỗi sẽ khác nhau tùy thuộc vào việc ProtectionHook có được cấu hình hay không.
→ Nếu ProtectionHook không được cấu hình: OS sẽ gọi ShutdownOS.
→ Nếu ProtectionHook được cấu hình: OS sẽ gọi ProtectionHook và yêu cầu chọn một trong năm tùy chọn sau:
(Thông tin về năm tùy chọn cụ thể không được cung cấp trong nội dung bạn đã gửi. Bạn có thể bổ sung thêm thông tin chi tiết về các tùy chọn này để hoàn thiện bản dịch.)
ProtectionReturnType ProtectionHook(StatusType Fatalerror)
{
…
return PRO_IGNORE; // Không thực hiện bất kỳ hành động nào
return PRO_TERMINATETASKISR; // Kết thúc TASK/ISR gặp vấn đề
return PRO_TERMINATEAPPL; // Kết thúc OS-Application chứa TASK/ISR gặp vấn đề
return PRO_TERMINATEAPPL_RESTART; // Khởi động lại OS-Application chứa TASK/ISR gặp vấn đề
return PRO_SHUTDOWN; // Tắt OS
}
