[CAN2.0][Controller Area Network][Bài 7] Quy định về trạng thái lỗi của CAN Node và tính hợp lệ của thông điệp

1. Các trạng thái lỗi của CAN Node

Để giám sát và kiểm soát lỗi, mỗi Node đều tự động xác định trạng thái của chính nó dựa trên số lượng lỗi mà nó phát hiện được. Tại một thời điểm, một Node có thể thuộc một trong ba trạng thái sau:

• Error active - Trạng thái chủ động với lỗi (gọi tắt là trạng thái lỗi chủ động). Đây là trạng thái hoạt động thông thường và tốt nhất của một Node. Node có thể tham gia truyền nhận dữ liệu trên bus một cách bình thường, nếu phát hiện lỗi thì sẽ phát khung báo lỗi với cờ báo lỗi chủ động (ACTIVE ERROR FLAG). Khi cờ báo lỗi chủ động được phát thì đường truyền bị ngắt ngay và các Node đều nhận biết được sự báo lỗi này vì cờ báo lỗi chủ động gồm 6 bit dominant sẽ phá vỡ cấu trúc thông thường của khung dữ liệu hoặc khung yêu cầu và không tuân theo luật chèn bit.
• Error warning - Trạng thái cảnh báo lỗi là trạng thái lỗi chủ động nhưng Node CAN lúc này giám sát thấy số lượng lỗi phát hiện được quá nhiều đến ngưỡng cần phải báo động để Node có cơ chế xử lý thích hợp. Node trong trạng thái này hoạt động như trong trạng thái lỗi chủ động. Đây là trạng thái không được quy định trong chuẩn CAN Specification 2.0 nhưng hều hết các CAN controller hiện tại đều có.
• Error Passive - Trạng thái bị động với lỗi (gọi tắt là trạng thái lỗi bị động). Một Node ở trạng thái này sẽ có một vài hoạt động bị giới hạn và kém ưu tiên hơn các Node ở trạng thái lỗi chủ động. Cụ thể, trong khi truyền nhận, nếu phát hiện một lỗi bus thì Node sẽ truyền khung báo lỗi bị động với cờ báo lỗi bị động (PASSIVE ERROR FLAG) toàn là bit recessive nên kém ưu tiên và thông điệp đang truyền có thể vẫn truyền tiếp. Mặt khác nó có thẻ bị ghi đè bởi các Node phát cờ báo lỗi chủ động. Một hạn chế nữa là, Node trong trạng thái lỗi bị động, sau khi vừa truyền xong một thông điệp thì phải chờ thêm một khỏng thời gian của vùng SUSPEND TRANSMISSION trước khi được phép truyền tiếp. Trong khoảng thời gian chờ này, nếu có Node khác truyền dữ liệu thì nó trở thành bộ nhận.
• Bus-off - Trạng thái ngắt khỏi bus CAN (gọi tắt là trạng thái ngắt bus) là trạng thái Node không được phép có bất cứ táng động nào trên bus. Bộ lái ngõ ra bus, nằm trong chip CAN transceiver, bị ngắt.

2. Cách xác định trạng thái lỗi

Mỗi Node sẽ có 2 bộ đếm được dùng để xác định trạng thái lỗi của Node là:

• Bộ đếm lỗi truyền (TRANSMIT ERROR COUNT)
• Bộ đếm lỗi nhận (RECEIVE EROR COUNT)

Hai bộ đếm lỗi này được tích hợp trong phần cứng CAN controller và chạy tự động khi Node CAN hoạt động.

Giá trị của hai bộ đếm lỗi là bộ đếm lỗi truyền (Tx_count) và bộ đếm lỗi nhận (Rx_count) sẽ quyết định Node đang trong trạng thái nào. Các khoảng giá trị của chúng được quy định như sau: 

• Trạng thái lỗi chủ động ‘Error active’ nếu Tx_count ≤ 127 và Rx_count ≤ 127. 
• Trạng thái lỗi bị động ‘Error passive’ nếu Tx_count > 127 hoặc Rx_count > 127 nhưng Tx_count ≤ 255. 
• Trạng thái ngắt bus ‘Bus off’ nếu Tx_count > 255.
• Trạng thái cảnh báo lỗi 'Error Warning' nếu Tx_count >= 96 hoặc Rx_count >= 96. Đây là trạng thái không được quy định trong CAN Specification 2.0 nhưng được tách ra dựa trên một chú ý (Note) trong chuẩn này. Cụ thể, giá trị của một bộ đếm lỗi lớn hơn "khoảng" 96 sẽ chỉ ra việc bus bị nhiễu nặng và có thể cần kiểm tra điều kiện này.

Hình 1. Các trạng thái của một CAN NODE

3. Các loại lỗi mà một Node CAN có thể phát hiện

Có 5 loại lỗi khác nhau và chúng không loại trừ lẫn nhau, nghĩa là một lỗi xảy ra có thể thuộc hơn 2 loại.

1. Lỗi bit (BIT ERROR) Một Node khi gửi một bit lên bus thì phải giám sát bit đó. Một lỗi bit được phát hiện ngay trong khoảng thời gian truyền bit đó nếu giá trị được lấy mẫu khi giám sát khác với giá trị bit được truyền ra. Nghĩa là truyền bit dominant nhưng giám sát thấy recessive và ngược lại. Ngoại trừ một số trường hợp dù giá trị gửi ra và giá trị bit giám sát khác nhau nhưng không được xem là lỗi bit, cụ thể như sau:
1. Gửi một bit recessive trong vùng ACK SLOT nhưng giám sát thấy một bit dominant.
2. Node gửi cờ báo lỗi bị động nhưng giám sát thấy có bit dominant xuất hiện
2. Lỗi chèn bit (STUFF ERROR) Một Node giám sát thấy chuỗi 5 bit liên tiếp giống nhau thì sẽ kiểm tra bit thứ 6 có khác cực với 5 bit trước hay không. Nếu không khác thì đây là lỗi chèn bit vì sau 5 bit dominant liên tiếp phải được chèn 1 bit recessive, sau 5 bit recessive liên tiếp phải được chèn 1 bit dominant.
3. Lỗi CRC (CRC ERROR) CRC SEQUENCE đi kèm theo thông điệp được tính bởi bộ truyền. Các bộ nhận phải tính lại chuỗi CRC giống với cách tính của bộ truyền. Kết quả tính toán này sẽ được dùng để so sánh với chuỗi CRC từ bộ truyền. Nếu hai chuỗi khác nhau thì đó là lỗi CRC.
4. Lỗi định dạng (FORM ERROR) Một Node giám sát thấy các vùng có định dạng bit cố định (các vùng quy định rõ mức logic cố định của bit là 1 hoặc 0) nhưng chứa 1 hoặc nhiều bit vi phạm quy định thì đó là lỗi định dạng. Ngoại trừ:
1. Một bộ nhận phát hiện thấy một bit dominant ở bit cuối cùng vùng EOF (bit thứ 7 của EOF) thì không xem đây là lỗi định dạng
5. Lỗi ACK (ACKNOWLEDGMENT ERROR) là lỗi được phát hiện bởi bộ truyền khi nó không thấy một bit dominant xuất hiện tròng vùng ACK SLOT.

Hình 2. Các vùng được giám sát lỗi

Một Node phát hiện thấy một trong các lỗi trên thì phải phát cờ báo lỗi chủ động hoặc bị động tùy vào trạng thái hiện tại của Node.

Đối với loại lỗi BIT, lỗi chèn bit, lỗi định dạng và lỗi ACK thì việc truyền cờ báo lỗi bắt đầu ngay ở bit kế tiếp ngay sau khi phát hiện lỗi.

Đối với loại lỗi CRC thì cờ báo lỗi chỉ được truyền sau vùng ACK DELIMITER trừ khi có một cờ báo lỗi sinh ra bởi điều kiện khác đang được truyền. Ví dụ, giả sử Node A và Node B đều ở trạng thái lỗi chủ động. Node A là transmitter phát hiện lỗi bit tại bit cuối của CRC Sequence bị lỗi (lỗi Bit). Node A phát cờ báo lỗi bắt đầu từ vùng đáng lẽ là CRC Delimiter và làm vi phạm định dạng bit của vùng CRC Delimiter. Node B không phát hiện ra lỗi ở bit cuối CRC Seuqence nhưng sau khi nhận bit cuối cùng của CRC Sequence thì Node B kiểm tra thấy lỗi CRC. Tuy nhiên, Node B giám sát thấy vùng CRC Delimiter bị lỗi (lỗi định dạng - FORM ERROR) nên Node B phát cờ báo lỗi của nó  bắt đầu từ vùng đáng lẽ là ACK SLOT chứ không chờ sau vùng ACK DELIMITER mới phát cờ báo lỗi để đáp ứng cho lỗi CRC.

Hình 3. Ví dụ về việc phát hiện lỗi và báo lỗi

4. Quy định về việc tăng/giảm giá trị các bộ đếm lỗi

Hai bộ đếm lỗi Tx_count và Rx_count khi nào tăng? khi nào giảm? giá trị tăng hoặc giảm là bao nhiêu? được quy định rõ ràng bởi chuẩn. Trong suốt quá trình truyền một thông điệp, các quy tắc tăng giảm bộ đếm lỗi sau đây sẽ được áp dụng:

1. Node là bộ nhận phát hiện một lỗi thì Rx_count tăng 1, ngoại trừ phát hiện lỗi bit khi phát cờ báo lỗi chủ động và cờ báo quá tải
2. Node là bộ nhận phát hiện một bit dominant ở bit đầu tiên sau khi phát một cờ báo lỗi thì Rx_count tăng 1
3. Node là bộ truyền phát một cờ báo lỗi thì Tx_count tăng 8. Tuy nhiên, Tx_count không thay đổi trong hai trường hợp ngoại lệ sau:
1. Ngoại lệ 1: Bộ truyền trong trạng thái lỗi bị động phát hiện lỗi ACK và không phát hiện một bit dominant nào trong khi gửi cờ báo lỗi bị động của nó.
2. Ngoại lệ 2: Nếu bộ truyền gửi một cờ báo lỗi sinh ra bởi lỗi chèn bit xuất hiện trong vùng phân xử mà bit chèn này đáng lẽ là recessive và bộ truyền đã truyền đi bit recessive nhưng lại được giám sát thấy là dominant
4. Node là bộ truyển phát hiện lỗi bit khi đang truyền cờ báo lỗi chủ động hoặc cờ báo quá tải thì Tx_count tăng 8
5. Node là bộ nhận phát hiện một lỗi bit trong khi gửi một cờ báo lỗi chủ động hoặc cờ báo quá tải thì Rx_count tăng 8
6. Sau khi gửi một cờ báo lỗi chủ động, cờ báo lỗi bị động hoặc cờ báo quá tải, nếu một Node phát hiện thêm 7 bit dominant liên tiếp thì:
1. Trong trường hợp của cờ báo lỗi chủ động và cờ báo quá tải, sau khi phát hiện bit dominant thứ 14 liên tiếp và sau mỗi chuỗi 8 bit dominant tiếp theo thì Tx_count và Rx_count tăng lên 8.
2. Trong trường hợp của cờ báo lỗi bị động, sau khi phát hiện bit dominant thứ 8 liên tiếp và sau mỗi chuỗi 8 bit dominant tiếp theo thì Tx_count và Rx_count tăng lên 8.
7. Sau khi truyền thành công một thông điệp (phát hiện được ACK và không có lỗi cho đến khi EOF kết thúc), Tx_count giảm 1 trừ khi Tx_count đang là 0 thì không giảm.
8. Sau khi nhận thành công một thông điệp (nhận không lỗi đến ACK SLOT và gửi thành công bit ACK) thì:
1. Rx_count giảm 1 nếu giá trị 1 ≤ Rx_count ≤ 127. 
2. Rx_count giữa giá trị 0 nếu nó đang bằng 0
3. Rx_count được gán một giá trị giữa 119 và 127 nếu Rx_count ≥ 127

Chú ý, trong quá trình khởi động (Start-up), chỉ có một Node được phép hoạt động. Nếu Node này truyền một số thông điệp, nó sẽ không nhận được ACK nên phát hiện ra lỗi và lặp lại việc truyền thông điệp. Node này có thể rơi vào trạng thái lỗi bị động nhưng không được phép bị bus-off vì lý do này.

5. Tính hợp lệ của thông điệp

Thời điểm xác nhận sự hợp lệ của thông điệp của bộ truyền và bộ nhận là khác nhau.

Với bộ truyền, thông điệp gọi là hợp lệ khi không có bất kỳ lỗi nào cho đến khi EOF kết thúc. nếu thông điệp bị lỗi thì thông điệp sẽ được tự động truyền lại dựa trên sự ưu tiên. Để có thể cạnh trang với sự truy cập bus từ các thông điệp khác thì việc truyền lại phải được bắt đầu sớm nhất có thể khi bus rảnh (BUS IDLE).

Với bộ nhận, thông điệp gọi là hợp lệ nếu nó không lỗi cho đến bit cuối của EOF. Giá trị bit cuối EOF, được bộ nhận xem như don't care. Bộ nhận phát hiện bit cuối này là dominant cũng không xem là một lỗi định dạng (FORM ERROR) mà đáp ứng lại bằng một khung báo quá tải.

Lịch sử cập nhật:

1) 2019.10.18 - Chỉnh sửa link hình minh họa