Quá trình truyền thông AUTOSAR CAN
Trình tự Khởi động (Start Sequence)
Sau khi khởi tạo ban đầu (Init), BswM sẽ bắt đầu quá trình truyền thông CAN.
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)
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.
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.
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.
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.
Xem thêm Chuyên Mục
