IOC
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.
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).
