Quá trình khởi tạo sau khi reset bộ xử lý có thể khác nhau tùy thuộc vào triển khai, nhưng OSEK OS hỗ trợ phương pháp khởi tạo chuẩn hóa. Các giao diện để khởi tạo phần cứng (Hardware), hệ điều hành (Operating System), và ứng dụng (Application) cần được định nghĩa rõ ràng.
• Trong quá trình generation hệ thống, Task và Alarm được thiết lập để tự động khởi động.
• Cung cấp StartupHook Routine để người dùng có thể khởi tạo Device Driver và các thành phần khác.
Khởi động Hệ Thống
1. Sau khi reset, người dùng có thể tự do thực thi Hardware Specific Code. Interrupt loại CAT 2 không thể thực thi đến 5 cấp độ. Non-Portable Section được duy trì cho đến khi phát hiện Application Mode.
2. Gọi StartOS với Application Mode làm tham số. Qua việc gọi này, hệ điều hành được khởi động.
3. Hệ điều hành thực hiện các chức năng Start-Up nội bộ để khởi tạo (không có scheduler đang hoạt động).
4. StartupHook được gọi để thực hiện mã khởi tạo do người dùng định nghĩa. Trong thời gian của Hook Routine, tất cả các interrupt của người dùng được vô hiệu hóa. Để cấu trúc mã khởi tạo trong StartupHook theo Application Mode, dịch vụ GetActiveApplicationMode được cung cấp.
5. Sau khi quay lại từ Hook Routine, hệ điều hành sẽ kích hoạt các interrupt và bắt đầu scheduler. Sau đó, hệ thống bắt đầu hoạt động và có thể thực thi User Task. Hệ điều hành sẽ bắt đầu Task và Alarm tự động khởi động được khai báo trong Application Mode hiện tại. Thứ tự kích hoạt của các Task tự động khởi động có cùng mức ưu tiên không được định nghĩa. Task tự động khởi động sẽ được thực hiện trước khi Alarm bắt đầu.
Hủy hệ thống
OSEK OS định nghĩa dịch vụ ShutdownOS để kết thúc hệ điều hành. Dịch vụ này có thể được yêu cầu bởi ứng dụng hoặc hệ điều hành khi xảy ra Fatal Error.
• Khi xảy ra Fatal Error, ứng dụng hoặc hệ điều hành có thể yêu cầu Shutdown (gọi ShutdownOS).
• Khi thực hiện ShutdownOS, ShutdownHook được gọi và sau khi Hook kết thúc, Shutdown sẽ được thực hiện.
• Người dùng thường có thể tự do định nghĩa hoạt động của hệ thống trong ShutdownHook.
• Không quay lại từ Hook Routine.
※ AUTOSAR OS sau khi gọi ShutdownHook sẽ vô hiệu hóa tất cả các interrupt và vào Infinite Loop.
Trong ngành công nghiệp ô tô, thường sử dụng CANoe của Vector để cấu hình CAN DB. CAN DB được lưu trữ dưới định dạng tệp DBC (CAN Bus Databases), trong đó bao gồm toàn bộ cấu trúc mạng (Network) do OEM ô tô định nghĩa, cũng như các thông điệp truyền và nhận của mỗi nút.
Cấu Hình Can Db
Cấu hình mạng toàn bộ
Các bộ điều khiển trên CAN Bus gửi và nhận dữ liệu theo định dạng như sau.
Cấu Hình Mạng Toàn Bộ
Để làm được điều này, cấu trúc mạng của tệp DBC được cấu hình như sau:
• Cấu trúc Network, ECU1, ECU2, …
• Thông điệp và tín hiệu.
Cấu Trúc Network, Ecu1, Ecu2
Loại hình truyền thông
Các bộ điều khiển thực hiện truyền thông dựa trên tín hiệu (Signal). Truyền thông có các loại sau đây tùy thuộc vào cổng được triển khai:
• Timing Communication: Sử dụng tác vụ định kỳ để gửi và nhận thông điệp theo chu kỳ.
• Event Communication: Gửi và nhận thông điệp khi cần thiết
Loại Hình Truyền Thông
Truyền thông dựa trên tín hiệu theo thời gian (Signal Based Timing Communication)
Quy trình thực hiện nhận tín hiệu (Phần về cách người dùng đọc tín hiệu)
1. Lưu tín hiệu đã nhận vào bộ đệm (Buffer) tương ứng của COM.
2. Thông qua việc gọi Notification, lưu dữ liệu vào bộ đệm Rte (Immediate / Deferred).
3. Thực thi Runnable theo chu kỳ đã định trong Timing Task.
4. ASW Runnable gọi RTE API để đọc tín hiệu tương ứng (Read).
Truyền Thông Dựa Trên Tín Hiệu Theo Thời Gian (signal Based Timing Communication)
Quy trình thực hiện gửi tín hiệu (Signal Transmission Execution Flow)
1. Timing Task thực thi Runnable một cách định kỳ.
2. Trong Runnable, sử dụng RTE API để ghi (Write) tín hiệu tương ứng.
3. Khi gửi tín hiệu, lưu tín hiệu đó vào COM tương ứng.
o COM BUFFER được cập nhật. Việc gửi tín hiệu thực tế phụ thuộc vào trạng thái truyền thông.
Quy Trình Thực Hiện Gửi Tín Hiệu (signal Transmission Execution Flow)
Truyền thông sự kiện dựa trên tín hiệu (Signal Based Event Communication)
Quy trình thực hiện nhận tín hiệu
1. Lưu tín hiệu đã nhận vào bộ đệm (Buffer) tương ứng của COM.
2. Thông qua việc gọi Notification, lưu dữ liệu vào bộ đệm RTE.
3. Thực hiện Event Task thông qua Data Received Event.
4. Trong Runnable tương ứng với Event Task, gọi RTE API để đọc (Read) tín hiệu tương ứng
Truyền Thông Sự Kiện Dựa Trên Tín Hiệu (signal Based Event Communication)
Quy trình thực hiện gửi tín hiệu
1. Thực thi Runnable trong Event Task.
2. Trong Runnable, sử dụng RTE API để ghi (Write) tín hiệu tương ứng.
3. Khi gửi tín hiệu, lưu tín hiệu đó vào COM tương ứng.
Quy Trình Thực Hiện Gửi Tín Hiệu
Quy trình thiết lập nhận tín hiệu
1. Tạo R-Port trong SW-C và kết nối với System Signal cần nhận.
2. Tạo Runnable để thực hiện công việc nhận và tạo RTE Event để thực thi Runnable, sau đó kết nối với R-Port.
3. Tạo Task trong OS để thực hiện công việc nhận.
4. Trong RTE, kết nối RTE Event với Task.
5. Trong COM, chỉ định Notification Function được gọi khi nhận Signal.
Quy Trình Thiết Lập Nhận Tín Hiệu
Quy trình thiết lập gửi tín hiệu
1. Tạo P-Port trong SW-C và kết nối với System Signal cần gửi.
2. Tạo Runnable để thực hiện công việc gửi và tạo RTE Event để thực thi Runnable, sau đó kết nối với P-Port.
3. Tạo Task trong OS để thực hiện công việc gửi.
4. Trong RTE, kết nối RTE Event với Task.
• Bộ đệm (Memory Buffer) tồn tại bên trong CAN Controller.
• Là tập hợp các Special Function Register liên quan đến CAN bên trong MCU.
→ Có thể thiết lập CAN ID, DLC, v.v., bằng cách ghi giá trị vào Special Function Register.
Truyền Thông Autosar Can Frame, Pdu, Signal
• Tùy thuộc vào thiết lập Direction, nó có thể được sử dụng để truyền hoặc nhận.
• BASIC CAN: Theo thiết lập Filter Mask, có thể sử dụng một Hardware Object để nhận hoặc truyền nhiều CAN Frame.
Quá trình nhận CAN Frame
1. CAN Controller phát hiện CAN Frame trên bus và lưu vào Hardware Object được chỉ định.
2. Pending Flag của Hardware Object nhận được CAN Frame được thiết lập thành 1.
o Nếu sử dụng ngắt, ngắt nhận sẽ được kích hoạt.
3. Hàm nhận của CAN Driver được thực thi bởi ngắt nhận hoặc hàm chu kỳ của CAN Driver.
4. CAN Driver chuyển đổi CAN Frame đã nhận thành PDU và chuyển cho mô-đun CanIf.
Quá trình truyền CAN Frame
1. Để truyền PDU từ mô-đun CanIf, PDU ID được chuyển đổi thành Hardware Object Handle và hàm truyền của CAN Driver được gọi.
2. CAN Driver sao chép dữ liệu cần truyền vào Hardware Object và thiết lập Request Flag thành 1.
3. CAN Controller tạo thành CAN Frame từ Hardware Object được yêu cầu truyền và gửi lên bus.
4. Khi xác nhận ACK bit trên bus, Pending Flag được thiết lập thành 1.
o Nếu sử dụng ngắt, ngắt hoàn thành truyền sẽ được kích hoạt.
5. CAN Driver thông báo cho mô-đun CanIf rằng việc truyền đã hoàn thành thông qua ngắt hoàn thành truyền hoặc hàm chu kỳ của CAN Driver (Notification).
6. Trong trường hợp CanIf có thiết lập hàng đợi truyền cho PDU đó và PDU cần truyền được lưu trữ, hàm truyền của CAN Driver sẽ được gọi lại.
7. Mô-đun CanIf thông báo về việc truyền hoàn thành đến mô-đun cấp cao hơn.
Ánh xạ Hardware Object với PDU
• Khi truyền và nhận CAN Frame, cần chuyển đổi giữa Hardware Object ID và PDU ID.
• Thông tin cần thiết cho việc chuyển đổi được thiết lập trong Configuration.
※ PDU (Protocol Data Unit): Dữ liệu được sử dụng trong nền tảng AUTOSAR.
Ánh Xạ Hardware Object Với Pdu
• HTH có nghĩa là Handling of Transmit Hardware Object.
• HTH 0, BUFFER 0, TX PDU ID = 0 đều là cùng một Signal, nhưng mỗi mô-đun lại đặt tên khác nhau. → Do đó, cần có Reference để tham chiếu.
PDU
• Trong nền tảng AUTOSAR, dữ liệu truyền thông được định nghĩa là PDU (Protocol Data Unit).
• PDU bao gồm Data, Length, Identifier, và PDU Reference
Data, Length, Identifier, Và Pdu Reference
1 CAN sử dụng các tầng Presentation, Network, và Data Link trong 7 tầng truyền thông OSI.
2 Tầng Presentation được chia nhỏ và thực hiện chức năng trong các mô-đun như AUTOSAR COM, DCM, PduR.
3 Tầng Network là TP (Transport Layer), hỗ trợ chia nhỏ và truyền nhận dữ liệu có kích thước lớn.
4 Tầng Data Link được thực hiện bởi CAN Controller.
1 Để truyền thông dựa trên PDU giữa các mô-đun BSW bên trong nền tảng, cần cấu hình PDU cho từng mô-đun.
2 PDU ID là duy nhất chỉ trong từng mô-đun nơi PDU được định nghĩa.
3 Trong trường hợp PDU được truyền trực tiếp giữa các mô-đun mà không thông qua PduR, PDU Reference sẽ được tham chiếu để tạo liên kết giữa các PDU, và PDU sẽ được truyền theo liên kết này.
Pdu Configuration Without Pdur
→ (PDU ID = 5, PDU REF = CANTP_MSG_1) và (PDU ID = 0, PDU REF = CANTP_MSG_1) có PDU ID khác nhau, nhưng PDU REF giống nhau, cho thấy đây là “cùng một tín hiệu”.
Cấu hình PDU với PduR
• Mô-đun PDU Router tham khảo Routing Table được thiết lập trước khi biên dịch để chuyển tiếp PDU mà nó nhận được đến các mô-đun khác.
Cấu Hình Pdu Với Pdur
• Trừ trường hợp PDU dành cho Gateway hoặc có nhiều hơn hai Destination, Source và Destination trong Routing Table được thiết lập cùng một PDU Reference.
• Src và Dest của PduR sử dụng PDU Reference chứ không phải PDU ID.
Định tuyến PDU dựa trên PDU Identifier
• PDU ID được thay đổi thành giá trị được định nghĩa tại mô-đun đích khi PDU được truyền giữa các mô-đun.
Cấu Hình Pdu Với Pdur
Chức năng truyền IPDU của mô-đun COM
• Mô-đun COM truyền IPDU theo chế độ truyền được thiết lập cho từng IPDU.
• Để IPDU được truyền, mô-đun COM phải ở trạng thái hoạt động, PDU Group chứa IPDU phải được kích hoạt, và ít nhất một trong các Signal thuộc IPDU phải được kích hoạt.
• Nếu các Signal thuộc IPDU có thuộc tính Filter, chế độ truyền của IPDU có thể thay đổi tùy thuộc vào việc vượt qua Filter.
o Nếu ít nhất một trong các Signal thuộc IPDU vượt qua Filter, IPDU sẽ được truyền ở chế độ TRUE.
o Nếu tất cả các Signal thuộc IPDU không vượt qua Filter, IPDU sẽ được truyền ở chế độ FALSE.
Chức năng Gateway của AUTOSAR CAN
1. Chức năng PDU to PDU Gateway Direct.
Chức Năng Gateway Của Autosar Can
• Chức năng PDU to PDU Gateway được xử lý bởi mô-đun PduR.
• Khi nhận được thông điệp, nó sẽ được gửi theo định nghĩa trong PduR Routing Table mà Gateway đang có.
• Không thể thay đổi giá trị của Signal.
• Chu kỳ hoặc phương thức truyền, là đặc tính riêng của thông điệp, sẽ không thay đổi.
• Khi sử dụng Direct Gateway, nếu độ dài dữ liệu nhận từ nguồn lớn hơn thông điệp đích, dữ liệu sẽ bị cắt bỏ để phù hợp với độ dài thông điệp đích.
2. Chức năng Signal to Signal Gateway Indirect.
Chức Năng Signal To Signal Gateway Indirect
• Chức năng Signal to Signal Gateway được xử lý bởi mô-đun COM.
• Khi nhận được thông điệp, mô-đun COM sẽ truyền theo từng Signal dựa trên cách thiết lập.
• Có thể thay đổi giá trị của Signal bằng cách sử dụng chức năng Signal Gateway Callout.
• Có thể thay đổi chu kỳ hoặc phương thức truyền, là đặc tính riêng của thông điệp.
• Kích thước của Source Signal và Target Signal phải giống nhau, nếu khác nhau thì cần được xử lý bởi App.
→ COM chuyển dữ liệu Signal lên ASW, sau khi được xử lý tại ASW, dữ liệu sẽ được gửi lại xuống COM.
Sử dụng chức năng CAN DB Import được cung cấp bởi Mobilgene C Studio để chuyển đổi tệp DBC (CAN DB) sang định dạng ARXML có thể sử dụng trong AUTOSAR.
Nhập Can Db
Cấu hình & Sinh mã cho ECU
Các mô-đun BSW tự động phản ánh thông tin CAN DB đã được chuyển đổi sang định dạng ARXML bao gồm:
• Can: Cấu hình kênh CAN, thông điệp, và tín hiệu.
• CanIf: Cấu hình kênh CAN, thông điệp, và tín hiệu.
• CanSM: Cấu hình kênh CAN.
• CanTp: Cấu hình kênh TP và PDU cho TP.
• PduR: Bảng định tuyến (Routing Table) cho PDU tương ứng với thông điệp CAN.
• COM: Cấu hình PDU và tín hiệu.
• EcuC: Cấu hình PDU Reference.
• ComM: Cấu hình kênh CAN.
• Nm: Cấu hình kênh Nm.
• BswM: Cấu hình điều khiển kênh CAN.
Cấu Hình & Sinh Mã Cho Ecu
Cấu hình COM IPdu
※ I-PDU: Interaction Layer PDU
• ComIPduCallout: Hàm được chỉ định sẽ được gọi trước khi truyền hoặc nhận PDU và có thể hủy quá trình truyền hoặc nhận PDU.
• ComIPduDirection: Chỉ định PDU này dành cho việc truyền hay nhận.
• ComIPduHandleId: PDU Identifier.
• ComIPduSignalProcessing:
o DEFERRED: Thông báo về hoàn thành truyền hoặc nhận được thực hiện trong Task.
o IMMEDIATE: Thực hiện ngay lập tức bởi hàm Notification.
• ComIPduGroupRef: Thiết lập ComIPduGroup (có thể kích hoạt hoặc hủy kích hoạt truyền thông theo nhóm).
• ComIPduSignalGroupRef: Chỉ định GroupSignal nếu thuộc PDU này.
• ComIPduSignalRef: Chỉ định các Signal thuộc PDU này.
• ComIPduIdRef: Chỉ định PDU Reference được thiết lập cho PDU này.
Cấu hình Chế độ truyền COM IPdu
Cấu Hình Chế độ Truyền Com Ipdu
ComTxModeMode
• ComTxModeMode:
o PERIODIC: Truyền theo chu kỳ
o DIRECT: Truyền theo sự kiện
o MIXED: Truyền cả theo chu kỳ và sự kiện
o NONE: Không truyền
• ComTxModeNumberOfRepetitions: Số lần lặp lại khi truyền
• ComTxModeRepetiotionPeriod: Chu kỳ giữa các lần truyền khi lặp lại
• ComTxModeTimeOffset: Trong trường hợp truyền theo chu kỳ, thời gian giữa việc kích hoạt chức năng truyền và lần truyền đầu tiên
• ComTxModeTimePeriod: Trong trường hợp truyền theo chu kỳ, chu kỳ truyền của PDU
Cấu hình COM ISignal
• ComNotification: Chỉ định hàm Notification được gọi khi hoàn thành việc truyền hoặc nhận Signal.
• ComTimeout:
o Trong trường hợp Signal nhận theo chu kỳ, chỉ định chu kỳ nhận.
o Trong trường hợp truyền, chỉ định thời gian giới hạn để hoàn thành truyền.
• ComTimeoutNotification: Chỉ định hàm Notification được gọi khi xảy ra Timeout.
• ComSignalInitValue: Chỉ định giá trị khởi tạo của Signal.
• ComErrorNotification: Chỉ định hàm Notification được gọi khi truyền thất bại.
• ComSystemTemplateSystemSignalRef: Chỉ định System Signal kết nối với RTE.
• ComDataInvalidAction:
o Nếu giá trị thiết lập là REPLACE, giá trị Signal được thiết lập thành ComSignalInitValue.
o Nếu giá trị thiết lập là NOTIFY, hàm Notification được chỉ định trong ComInvalidNotification sẽ được gọi.
• ComSignalDataInvalidValue: Khi nhận được giá trị đã thiết lập, giá trị Signal sẽ được thiết lập thành ComSignalInitValue.
• ComInvalidNotification: Chỉ định hàm Notification.
ComTransferProperty
• PENDING: Chỉ cập nhật giá trị Signal.
• TRIGGERED: Cập nhật giá trị Signal và sau đó yêu cầu truyền.
• TRIGGERED_ON_CHANGE: Chỉ yêu cầu truyền khi giá trị thay đổi.
• TRIGGERED_ON_CHANGE_WITHOUT_REPETITION: Chỉ yêu cầu truyền khi giá trị thay đổi (không lặp lại).
• TRIGGERED_WITHOUT_REPETITION: Cập nhật giá trị Signal và sau đó yêu cầu truyền (không lặp lại).
Các mô-đun chịu trách nhiệm về chức năng chẩn đoán trong AUTOSAR bao gồm DCM, DEM, và DET.
Ngăn Xếp Chẩn đoán (diagnostic Stack)
DCM là gì?
• Thuộc Communication Services Layer trong AUTOSAR Stack, chịu trách nhiệm xử lý yêu cầu dịch vụ chẩn đoán (Request) và phản hồi (Response).
• Quản lý Data Flow và State của truyền thông chẩn đoán, thực hiện yêu cầu chẩn đoán của thiết bị chẩn đoán.
• Yêu cầu thay đổi trạng thái như Reset, Session, v.v., đến BswM.
• Yêu cầu trạng thái Full-Communication, Silent-Communication, No-Communication, v.v., đến ComM.
• Yêu cầu thông tin DTC (Diagnostic Trouble Code) từ Dem.
• Truyền dữ liệu chẩn đoán thông qua PduR.
Hành vi của DCM
DCM có ba loại hành vi sau:
1. Cung cấp các Dịch vụ của nền tảng
2. Cung cấp Dịch vụ của nền tảng + Application Callback.
3. Cung cấp Dịch vụ của nền tảng + Application Services (Dịch vụ do người dùng định nghĩa).
DCM Call Stack
Diagnostic Message có Call Stack như sau, từ CAN Controller đến SW-C.
Các giao thức theo từng lớp truyền thông (Communication Layer) cần thiết để hiểu về chẩn đoán truyền thông được thể hiện trong bảng dưới đây.
Autosar Dcm – Protocol Overview
Định nghĩa Giao thức: Tầng Vật lý (Physical Layer)
• Giao thức CAN
• Tầng vật lý của chẩn đoán truyền thông tuân theo tầng vật lý của CAN.
• Được chia thành hai loại chính: CAN tốc độ cao (500 kbps) và CAN tốc độ thấp (100 kbps), với các đặc điểm được thể hiện trong bảng dưới đây.
Định Nghĩa Giao Thức – Tầng Vật Lý (physical Layer)
Định nghĩa Giao thức: Tầng Liên kết Dữ liệu (Data Link Layer)
• Giao thức UDS (Unified Diagnostic Services)
• Là giao thức dịch vụ chẩn đoán xe dựa trên ISO 14229-1:2013, các dịch vụ chẩn đoán (Diagnostic Services) do từng OEM ô tô cung cấp có thể khác nhau.
Tầng Liên Kết Dữ Liệu (data Link Layer)
Định nghĩa Giao thức: Tầng Mạng (Network Layer)
1. Chế độ địa chỉ (Addressing Mode)
• Truyền thông chẩn đoán dựa trên CAN tuân theo định dạng 11-bit CAN Identifier được định nghĩa trong ISO 15765-2 và có hai loại Addressing Mode sau:
• Functional Addressing (Truyền thông 1-n): Chỉ áp dụng cho thông điệp Single Frame, và Functional Rx Address của Dcm có giá trị cố định là 0x7DF.
• Physical Addressing (Truyền thông 1-1): Áp dụng cho mọi loại thông điệp.
Tầng Mạng (network Layer)
2. Data Stream
– Single Frame(SF) Transmission
Data Stream
Truyền đa khung (Multi Frame Transmission)
• Phương pháp truyền dữ liệu vượt quá 8 byte.
• Sender chia dữ liệu thành First Frame và Consecutive Frame để truyền, và Receiver sẽ gửi Flow Control.
Truyền đa Khung (multi Frame Transmission)
3. Cấu trúc Thông điệp CAN (CAN Message Structure)
• Nội dung được điền vào CAN frame khác nhau tùy theo loại CAN frame và được thể hiện trong bảng dưới đây.
Cấu Trúc Thông điệp Can (can Message Structure)
4. Tham số Thời gian Tầng Mạng (Network Layer Timing Parameters)
Có 6 tham số thời gian: N_As, N_Ar, N_Bs, N_Br, N_Cs, và N_Cr. Ý nghĩa của từng tham số được thể hiện trong hình và bảng dưới đây.
Tham Số Thời Gian Tầng Mạng (network Layer Timing Parameters)Network Layer Timing Parameters
Định nghĩa Giao thức: Tầng Ứng dụng (Application Layer)
1. Request Message: SuppressPosRspMsgIndicationBit
o Trong trường hợp dịch vụ hỗ trợ Subfunction dựa trên Service Parameter, byte tiếp theo được xử lý như là Subfunction Parameter.
o Subfunction Parameter Byte được chia thành hai phần.
2. Response Message (Trong trường hợp yêu cầu được địa chỉ hóa vật lý – Physical Addressed Request Message)
o Nếu Subfunction được hỗ trợ và SuppressPosRspMsgIndicationBit là TRUE, sẽ không có phản hồi (No Response).
3. Response Message (Trong trường hợp yêu cầu được địa chỉ hóa chức năng – Functional Addressed Request Message)
o Nếu Subfunction được hỗ trợ và SuppressPosRspMsgIndicationBit là TRUE, sẽ không có phản hồi (No Response).
o Không có phản hồi đối với các phản hồi tiêu cực như ServiceNotSupported, subfunctionNotSupported, requestOutOfRange.
4. Application Layer Timing Parameters
o P2CAN_SERVER: Thời gian từ khi nhận Request đến khi xử lý xong Response.
o P2*CAN_SERVER: Thời gian từ khi xử lý 0x78 (Response Pending) đến khi xử lý Response tiếp theo.
5. Session Layer Timing Parameter
o S3SERVER: Thời gian duy trì của Diagnostic Session.
Bảng Lịch Trình Autosar – OSEK Counter và một loạt auto-start Alarm có thể được sử dụng để triển khai cơ chế kích hoạt Task được định nghĩa tĩnh. Trong trường hợp đơn giản, điều này có thể được thực hiện bằng cách chỉ định rằng Alarm không bị thay đổi sau khi bắt đầu. Chỉ có thể sửa đổi Alarm khi có thể đảm bảo sự đồng bộ tương đối giữa các Alarm. Điều này thường có nghĩa là sửa đổi Alarm khi Counter Tick Interrupt liên quan bị vô hiệu hóa.
Mỗi Schedule Table có một thời gian (Duration) theo đơn vị Tick. Thời gian này được đo từ 0 và định nghĩa Modulus của lịch trình.
Trong thời gian thực, mô-đun hệ điều hành sẽ lặp lại bảng và xử lý từng Expiry point lần lượt. Bảng được điều khiển lặp đi lặp lại bởi OSEK Counter. Do đó, thuộc tính của Counter ảnh hưởng đến các mục có thể cấu hình trong bảng.
• Tập hợp các Expiry point được định nghĩa tĩnh.
• Khi vượt qua Offset đã chỉ định và đến Expiry point, thực hiện Action được định nghĩa tại mỗi Expiry point.
• Thực hiện từng Expiry point trong khoảng thời gian Duration, và có thể lặp lại theo cấu hình.
Bảng Lịch Trình
Alarm vs. Schedule Table
Alarm
• 1 Alarm có thể kích hoạt 1 TASK duy nhất.
• Nếu có nhiều Alarm trong một AUTOSAR OS, có thể xảy ra tình trạng nhiều TASK chồng chéo khi được kích hoạt.
Ví dụ, nếu có Task1 hoạt động với Alarm chu kỳ 10 ms và Task2 hoạt động với Alarm chu kỳ 20 ms, có thể xảy ra việc Task1 và Task2 chồng chéo tại 20 ms (ước số chung lớn nhất của hai chu kỳ).
→ Khi gửi và nhận dữ liệu trong TASK qua mạng xe hơi, có thể xảy ra độ trễ trong việc thực hiện TASK, dẫn đến việc gửi dữ liệu vượt quá thời gian quy định.
Schedule Table
• Schedule Table được thiết kế để cải thiện nhược điểm của Alarm, đảm bảo rằng nhiều TASK không bị chồng chéo khi thực thi.
Tuy nhiên, nếu TASK đã đăng ký trong Schedule Table không hoàn thành trong khoảng thời gian quy định, sẽ gây ra độ trễ cho TASK tiếp theo. Do đó, cần phải kiểm tra xem các TASK trong Schedule Table có hoàn thành đúng hạn không.
Các thành phần của Expiry Point
• Action: Định nghĩa kích hoạt một hoặc nhiều Task hoặc cài đặt Event.
• Offset: Tick tính từ điểm bắt đầu của Schedule Table.
Alarm Vs. Schedule Table
Hoạt động của Schedule Table
• Thực hiện các công việc từ Initial Expiry Point đến Final Expiry Point theo thứ tự tăng dần của Offset.
• Có thể thực hiện nhiều Schedule Table đồng thời.
• Có thể được cấu hình để tự động bắt đầu khi Start-up hoặc khởi động bằng cách gọi trực tiếp.
• Có thể cấu hình để thực thi lặp lại tùy theo thiết lập:
o Single Shot: Thực hiện một lần rồi kết thúc.
o Repeating: Thực hiện lặp lại.
※ AUTOSAR OS hỗ trợ chức năng Schedule Table, nhưng AUTOSAR SWP (nền tảng phần mềm) không hỗ trợ chức năng này.
Trong hệ điều hành OS, thuật ngữ Resource đề cập đến bất kỳ dữ liệu hoặc thứ tự thực thi nào có thể được sử dụng. Nói cách khác, Resource là vùng quan trọng được chia sẻ với các Task khác như CPU, bộ nhớ, thiết bị, bộ lập lịch (Scheduler). Do đó, Quản lý tài nguyên (Resource Management) là quá trình điều chỉnh thứ tự sử dụng để nhiều Task với mức độ ưu tiên khác nhau có thể chia sẻ Resource một cách an toàn.
Lưu ý rằng Quản lý tài nguyên chỉ áp dụng cho các hệ điều hành và không thể sử dụng cho môi trường đa lõi (Multi-Core). Trong môi trường Multi-Core, các phương pháp khác như Spinlock được sử dụng.
Resource Type
1. Standard
o GetResource(ResID): API để thu nhận Resource.
o ReleaseResource(ResID): API để trả lại Resource.
2. Internal
o Resource được tự động thu nhận khi Task chuyển sang trạng thái Running.
o GetResource(ResID) và ReleaseResource(ResID) không thể sử dụng.
o Được tự động giải phóng tại điểm tái lập lịch (Re-Scheduling) trong lập lịch không chiếm quyền (Non-Preemptive Scheduling).
o Hành vi cơ bản tương tự như Standard Resource (như Priority Ceiling Protocol).
3. Linked
o Không thể chiếm giữ lồng nhau (Nesting) đối với Resource.
o Nếu cần lồng nhau (Nesting), thêm Link Resource thực hiện cùng một hành vi như Resource ban đầu.
Khi một Task chiếm dụng Resource trong một nhóm sử dụng cùng Resource, các Task khác trong nhóm đó sẽ không được chiếm quyền.
Resource Type
Priority Ceiling Protocol
OSEK OS áp dụng phương pháp Priority Ceiling Protocol (Giao thức trần ưu tiên).
Priority Ceiling Protocol là phương pháp giải quyết tình trạng bế tắc (Deadlock) và đảo ngược ưu tiên (Priority Inversion) có thể xảy ra khi một Task có mức độ ưu tiên thấp hơn chiếm giữ (Preemption) Resource. Bằng cách gán một Ceiling-Priority (trần ưu tiên) cho từng Resource và thiết lập mức độ ưu tiên cao nhất cho Task cần Resource, chỉ có một Task duy nhất có thể chiếm giữ Resource tại một thời điểm.
Hình minh họa bên dưới cho thấy kỹ thuật Ceiling-Priority. Task T0 có mức độ ưu tiên cao nhất, và Task T4 có mức độ ưu tiên thấp nhất. Khi Task T1 và Task T4 cùng muốn truy cập vào một Resource, Task T1 có mức độ ưu tiên cao hơn sẽ chiếm giữ Resource với thời gian chờ ngắn hơn thời gian chiếm giữ tối đa của Task T4
Priority Ceiling Protocol
1. Gán Ceiling-Priority (trần ưu tiên) cho từng Resource.
2. Task có mức độ ưu tiên cao nhất trong số các Task cần Resource sẽ được cấp quyền sử dụng Resource.
3. Tại thời điểm Task nhận Resource, mức độ ưu tiên của Task được thiết lập theo Ceiling-Priority của Resource.
4. Khi Task giải phóng (Release) Resource, Task sẽ quay lại mức độ ưu tiên ban đầu.
5. Nếu chính sách lập lịch (Scheduling Policy) là Preemptive, việc lập lịch sẽ xảy ra.
Ràng buộc
• Không thể chiếm giữ lồng nhau (Nested Acquisition) đối với Resource.
• Task và ISR (Interrupt Service Routine) không thể kết thúc nếu đang chiếm giữ Resource.
• Không thể gọi các API như TerminateTask, ChainTask, Schedule, và WaitEvent.
• Khi một Task chiếm giữ nhiều Resource, người dùng phải yêu cầu và giải phóng Resource theo thứ tự LIFO (Last In First Out, ngăn xếp).
o ※ Nếu không giải phóng Resource theo thứ tự, hệ thống có thể gặp tình trạng bế tắc (Deadlock).
• Mức độ ưu tiên của Task sử dụng Resource không được cao hơn mức độ ưu tiên đã gán cho Resource.
Scheduler as a Resource
Scheduler tự nó là một Resource.
• Task có thể khóa Scheduler để tránh bị chiếm quyền bởi các Task khác.
• Trong OSEK/VDX, Standard Resource có tên là RES_SCHEDULER được tự động tạo.
o ※ Trong trường hợp của AUTOSAR, RES_SCHEDULER không được tạo tự động.
• RES_SCHEDULER ngăn chặn việc tái lập lịch (Re-Scheduling) của các Task (ngoại trừ Interrupt).
• Sử dụng GetResource(RES_SCHEDULER) và ReleaseResource(RES_SCHEDULER).
Interrupt đóng vai trò quan trọng trong việc đồng bộ hóa với các sự kiện bên ngoài. Nó xảy ra khi phát hiện các thay đổi trạng thái trong các thiết bị ngoại vi, chẳng hạn như khi nhận tín hiệu CAN hoặc khi bộ đếm thời gian (Timer) hết hạn.
Vì Interrupt xảy ra ở cấp độ phần cứng, OS quản lý nó và gọi ISR (Interrupt Service Routine). (Bất kể Full Preemptive hay Non-Preemptive, Interrupt sẽ chiếm quyền của Task và Context Switching sẽ xảy ra!)
• Mức độ ưu tiên (Priority): Interrupt Level > Logical Level for Scheduler > Task Level.
Interrupt Osek Operating System
Interrupt Processing
ISR (Interrupt Service Routine) có thể được phân loại thành hai loại: Category 1 (CAT 1) và Category 2 (CAT 2).
Interrupt Processing
ISR Category 1 (CAT 1)
• Đứng ở vị trí cao nhất trong các loại ISR.
• Không sử dụng dịch vụ của OS, không yêu cầu Interrupt thông qua dịch vụ API.
• Sau khi ISR kết thúc, tiếp tục xử lý câu lệnh đang được thực thi ngay trước đó.
• Interrupt không ảnh hưởng đến quản lý Task.
• Có Overhead tối thiểu, là Interrupt Routine nhanh nhất.
ISR Category 2 (CAT 2)
• Sử dụng dịch vụ của OS, yêu cầu Interrupt thông qua dịch vụ API.
• OS cung cấp ISR-frame để cung cấp môi trường chạy thời gian thực (Runtime Environment) cho routine người dùng được chỉ định.
• Routine người dùng được gán cho Interrupt trong quá trình tạo hệ thống (System Generation).
• Thường cần Counter, Task, Event hoặc Message.
Lập lịch (Scheduling) giữa Interrupt và Task
Không xảy ra tái lập lịch (Re-Scheduling) trong khi thực hiện ISR.
• Thực hiện tái lập lịch cho Task sau khi CAT 2 ISR kết thúc và không có Interrupt nào khác xảy ra.
• Task được kích hoạt (Active) từ Interrupt sẽ chỉ có thể được lập lịch sau khi tất cả các ISR đã kết thúc.
Interrupt Lồng nhau (Nested Interrupt) của các Category Khác nhau
• Tình huống vấn đề: Trong khi đang thực hiện CAT 1 ISR, CAT 2 ISR xảy ra và kích hoạt (Activate) một Task. Sau khi CAT 1 ISR kết thúc, do không gọi đến OS, dẫn đến việc Task được kích hoạt gặp phải độ trễ không giới hạn (Unbounded Delay).
• Giải pháp: Đảm bảo tất cả CAT 1 ISR có mức độ ưu tiên không bằng hoặc cao hơn CAT 2 ISR.
API List
• void EnableAllInterrupts (void) / void DisableAllInterrupts (void)
o Bật/Tắt tất cả các Interrupts.
o Chặn cả tín hiệu phần mềm và phần cứng.
o Không ghi nhớ trạng thái trước đó của ISR.
o Không cho phép Nesting.
• void ResumeAllInterrupts (void) / void SuspendAllInterrupts (void)
o Bật/Tắt tất cả các Interrupts.
o Chặn cả tín hiệu phần mềm và phần cứng.
o Ghi nhớ trạng thái trước đó của ISR.
o Cho phép Nesting.
• void ResumeOSInterrupts (void) / void SuspendOSInterrupts (void)
o Bật/Tắt tất cả các Interrupts thuộc CAT 2.
o Chỉ chặn tín hiệu phần mềm, chỉ bỏ qua Interrupts từ phần mềm bên ngoài.
o Không ghi nhớ trạng thái trước đó của ISR.
o Cho phép Nesting.
※ Nesting: Việc gọi lồng nhau cùng một API. Để kích hoạt lại Interrupt đã bị treo (Suspend), cần gọi Resume Interrupt tương ứng với số lần Suspend Interrupt đã được gọi lồng nhau.
Event là một cấu trúc dữ liệu đại diện cho một sự kiện cụ thể có thể xảy ra trong hệ thống và được sử dụng như một phương tiện đồng bộ hóa. Event được sử dụng để đồng bộ hóa thứ tự hoạt động giữa các Task hỗ trợ trạng thái Waiting. Trong AUTOSAR OS, chỉ có Extended Task mới có thể sử dụng Event. Extended Task sẽ chờ đợi trong trạng thái Waiting cho đến khi một Event cụ thể xảy ra.
Extended Task có thể chuyển sang trạng thái Waiting để chờ đợi một Event cụ thể và ngừng thực thi, hoặc một Task khác có thể kích hoạt Event để đánh thức Task đang ở trạng thái Waiting và chuyển nó sang trạng thái Ready để tiếp tục thực thi. Ví dụ, Task B có thể cần kết quả tính toán từ Task A, do đó Task B sẽ chờ đợi (Wait) cho đến khi Task A phát ra Event báo hiệu rằng kết quả đã sẵn sàng.
Event Mechanism
• Tất cả các Task không ở trạng thái Suspended đều có thể thiết lập Event (Set Event) cho Extended Task (bao gồm cả Basic Task).
• Extended Task ở trạng thái Running sẽ chờ đợi trong trạng thái Wait cho đến khi Event được chỉ định xảy ra.
• Khi Event mà Extended Task đang chờ đợi xảy ra, Extended Task ở trạng thái Waiting sẽ chuyển sang trạng thái Ready.
• Nếu Event đã xảy ra và Extended Task đang ở trạng thái Running khi nó chờ đợi Event, thì Task sẽ duy trì trạng thái Running.
• Extended Task có một Event Number.
• Chỉ Extended Task ở trạng thái Wait mới có thể xóa (Clear) Event đó.
Event Mechanism
Hình trên là biểu đồ thời gian của quá trình đồng bộ giữa Task T1 và Task T2. Khi Task T2 phát sinh một Event, thông điệp sự kiện sẽ được truyền đến Task T1 và sau đó được yêu cầu đến Scheduler. Scheduler sẽ chuyển Task T1 từ trạng thái Waiting sang Ready, sau đó đến trạng thái Running, đồng thời chuyển Task T2 từ trạng thái Running sang Ready. Sau khi xử lý Event xong, trạng thái của các Task sẽ được chuyển đổi về trạng thái ban đầu.
API List
• StatusType SetEvent (TaskType <TaskID>, EventMaskType <Mask>)
o Nếu Event <Mask> mà Task <TaskID> đang chờ, chuyển trạng thái của Task từ Waiting sang Ready.
• StatusType ClearEvent (EventMaskType <Mask>)
o Hủy kích hoạt Event hiện tại.
o Chỉ có Task sở hữu Event muốn hủy mới có thể sử dụng.
• StatusType GetEvent (TaskType <TaskID>, EventMaskRefType <Mask>)
o Trả về trạng thái bit của tất cả các Event mà Task <TaskID> đang có.
• StatusType WaitEvent (EventMaskType <Mask>)
o Chuyển non-suspended extended Task sang trạng thái Wait.
※ StatusType: Được sử dụng để lưu trữ thông tin trạng thái đối với tất cả các dịch vụ API.
