Truyền các tin nhắn khác nhau với ID CÙNG trên xe buýt CAN


12

Trọng tài CAN được thực hiện với ID và bất kỳ nút nào trên xe buýt có thể truyền với bất kỳ ID nào (lý tưởng là không nên, nhưng một nút khó chịu có thể).

Điều gì xảy ra nếu hai nút khác nhau được kết nối trên cùng một bus CAN truyền tin nhắn có cùng ID nhưng byte dữ liệu khác nhau?

Suy nghĩ của tôi: Nó sẽ tạo ra rác trên xe buýt. Bất cứ ai có bit trội sẽ chỉ được truyền đi.


1
Tôi không chắc tại sao họ lại làm theo cách này. Tôi đã nghĩ rằng sẽ có ý nghĩa hơn đối với trọng tài áp dụng cho toàn bộ thông điệp.
Rocketmagnet

Câu trả lời:


12

Mục 6.1 của thông số CAN :

BIT ERROR: Một đơn vị đang gửi một chút trên xe buýt cũng giám sát xe buýt. Một BIT ERROR phải được phát hiện tại thời điểm bit đó, khi giá trị bit được theo dõi khác với giá trị bit được gửi. Một ngoại lệ là việc gửi bit 'recessive' trong luồng bit nhồi của L FINH VỰC ARBITRATION hoặc trong ACK SLOT.

Vì vậy, nút đầu tiên truyền '1' khi nút kia truyền '0' sẽ lưu ý Lỗi Bit và sau đó báo hiệu lỗi như bình thường - bằng cách truyền cờ lỗi (xem Phần 3.1.3), như được mô tả chính thức trong mục 6.2.

Một cách không chính thức, nếu nút đó hoạt động lỗi (nên là trường hợp thông thường), nó sẽ truyền một cờ lỗi gồm 6 bit trội, mà tất cả các nút khác cũng sẽ phát hiện (như một lỗi công cụ). Điều này có tác dụng phá hủy hoàn toàn thông điệp đó:

  • không ai sẽ nhận được nó
  • không ai trong số các máy phát sẽ nghĩ rằng họ đã truyền tải thành công bất cứ thứ gì.

Mỗi máy phát sau đó sẽ cố gắng truyền lại - tùy thuộc vào thời gian truyền lại chính xác, người ta có thể bắt đầu đủ trước khi người kia kiểm soát mức tăng của xe buýt. Nếu không, trình tự tương tự có thể xảy ra một lần nữa. (Hoặc một tin nhắn ưu tiên cao hơn khác có thể khiến cả hai tắt trong một thời gian!)


Câu trả lời mở rộng lấy cảm hứng từ câu trả lời của @ clabbacchio bên dưới.

Bạn đề cập đến "các nút khó chịu" và clabbacchio đưa ra điểm hợp lệ rằng nếu hai nút truyền vào các thời điểm khác nhau, mỗi người nhận cần quyết định phải làm gì với nhiều lần tiếp khách.

Điều này đã được chứng minh bằng một vụ hack năm ngoái . Bài viết thảo luận, trong phần "Thông tin cụ thể về PSCM", làm thế nào kẻ tấn công có thể đồng bộ hóa với các tin nhắn thông thường trên xe buýt và phát thông điệp xấu xa của chúng ngay trước khi ECU "tốt" sắp gửi. ECU nhận sẽ chấp nhận tin nhắn trước đó, cập nhật bộ đếm tin nhắn và sau đó loại bỏ các tin nhắn "tốt" là sai, vì bộ đếm tin nhắn của nó không tăng lên.


1

Trong câu hỏi của bạn, bạn đưa ra giả thuyết này:

Bất cứ ai có bit trội sẽ chỉ được truyền đi.

Giả định rằng hai tin nhắn được truyền đi cùng một lúc, đó là một trường hợp cụ thể của một vấn đề tổng quát hơn. Câu trả lời hợp lệ của Martin bao gồm vấn đề cụ thể này, nhưng bỏ qua trường hợp (tổng quát hơn) trong đó hai nút truyền tại các thời điểm khác nhau.

Trong trường hợp đó, sẽ có hai tin nhắn có cùng ID nhưng tải trọng khác nhau lưu hành trên xe buýt và tùy thuộc vào logic của người nhận để phân biệt giữa hai tin nhắn và quyết định xem đó có phải là nội dung họ cần nhận hay không. Nếu họ không phân biệt được hai thông báo, họ có thể hiểu sai dữ liệu và gây ra các vấn đề nghiêm trọng hơn là chỉ các khung lỗi.

Ví dụ, nói rằng một tin nhắn chứa cảm biến nhiệt độ, tin nhắn kia chứa vị trí mục tiêu của bộ chấp hành trên cùng một byte (NÊN KHÔNG BAO GIỜ HẠNH PHÚC TRONG CUỘC SỐNG THỰC SỰ), bạn có thể có bộ chấp hành lấy đó làm mục tiêu mà không cần biết.


Có, một logic nên được thực hiện để phân biệt giữa hai thông điệp. Nhưng câu hỏi của tôi là nếu phân xử được thực hiện trên cơ sở ID, thì điều gì sẽ xảy ra nếu ID thông báo giống nhau và dữ liệu khác nhau.
Swanand

@Swanand chỉ dựa trên giả thuyết truyền đồng thời? Chỉ cần lưu ý rằng đó là một trường hợp góc, nhiều khả năng ngược lại
clabacchio

0

Nếu trường dữ liệu tin nhắn khác nhau, bạn sẽ (hy vọng!) Nhận được khung lỗi trên xe buýt do CRC sai.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.