Phần 5 – CAN Error Handling & Bus-Off

Hôm nay, BKAII và các bạn sẽ tiếp tục bước vào phần 5 của Series Can Bus nhé. Một trong những lý do khiến CAN Bus được sử dụng rộng rãi trong ô tô và công nghiệp là cơ chế phát hiện và xử lý lỗi cực kỳ chặt chẽ. Không giống nhiều giao thức khác, CAN không chỉ phát hiện lỗi mà còn:

• Tự đánh giá mức độ lỗi của từng node
• Cô lập node gây lỗi
• Bảo vệ toàn bộ mạng khỏi sụp đổ

1. Các loại lỗi trong CAN

Như các bạn đã biết, giao thức CAN (Controller Area Network) được thiết kế cho các hệ thống điều khiển yêu cầu độ tin cậy rất cao. Vì vậy, ngay từ tầng Data Link, CAN đã tích hợp nhiều cơ chế phát hiện lỗi mạnh mẽ, cho phép node phát hiện sai lệch chỉ trong vài bit và phản ứng ngay lập tức.

Các lỗi trong CAN có thể xảy ra ở mức bit hoặc frame. Khi phát hiện lỗi, node sẽ chủ động phát Error Frame để thông báo toàn mạng rằng frame hiện tại là không hợp lệ.

1.1 Bit Error (Lỗi bit)

Bit Error xảy ra khi một node CAN gửi một bit nhưng đọc lại bus thấy giá trị khác.

Nguyên lý của CAN là: node phát luôn đồng thời giám sát bus. Nếu node gửi bit recessive (1) nhưng trên bus lại xuất hiện dominant (0), node sẽ xác định có lỗi.

Ví dụ dễ hiểu:

• Node A gửi bit 1 (recessive)
• Nhưng do nhiễu, short mạch hoặc node khác lỗi, bus bị kéo xuống 0
• Node A đọc lại thấy 0 ≠ 1 → phát hiện Bit Error

Bit Error thường liên quan đến: nhiễu điện từ (EMI), lỗi đấu dây, termination sai hoặc xung cạnh tín hiệu bị méo.

1.2 Stuff Error (Lỗi chèn bit)

CAN sử dụng cơ chế bit stuffing để đảm bảo luôn có đủ cạnh tín hiệu cho việc đồng bộ.

Quy tắc: Sau 5 bit liên tiếp giống nhau (00000 hoặc 11111), node phát bắt buộc phải chèn 1 bit ngược lại.

Nếu node nhận phát hiện: hơn 5 bit giống nhau liên tiếp mà không có bit chèn → xảy ra Stuff Error.

Ví dụ:

• Chuỗi hợp lệ: 111110111
• Chuỗi lỗi: 111111 (6 bit 1 liên tiếp, không có bit chèn)

Stuff Error thường xuất hiện khi: nhiễu làm mất bit, lỗi timing hoặc phần cứng CAN controller hoạt động bất thường.

1.3 CRC Error (Lỗi kiểm tra CRC)

Mỗi CAN frame đều chứa trường CRC, dùng để kiểm tra tính toàn vẹn dữ liệu.

Quá trình hoạt động:

• Node phát tính CRC dựa trên nội dung frame
• Node nhận cũng tự tính lại CRC
• Nếu CRC nhận được ≠ CRC tính toán → CRC Error

Nguyên nhân thường gặp:

• Nhiễu điện từ làm lật bit dữ liệu
• Timing sai (sample point đặt không hợp lý)
• Dây CAN quá dài so với bitrate

CRC Error là loại lỗi rất quan trọng, vì nó phát hiện được lỗi mà mắt thường hoặc logic đơn giản không thấy.

1.4 Form Error (Lỗi định dạng frame)

Trong CAN frame, một số bit có giá trị cố định theo chuẩn, ví dụ:

• EOF (End of Frame) phải gồm 7 bit recessive liên tiếp
• ACK delimiter luôn phải là recessive

Nếu node nhận thấy các trường này không đúng định dạng → xảy ra Form Error.

Ví dụ:

• EOF xuất hiện bit dominant → Form Error
• ACK delimiter bị kéo xuống dominant → Form Error

Form Error thường liên quan đến: nhiễu mạnh, lỗi phần cứng transceiver hoặc timing quá lệch giữa các node.

1.5 ACK Error (Lỗi xác nhận)

Trong CAN, mỗi frame hợp lệ phải được ít nhất một node khác xác nhận bằng cách kéo bit ACK xuống dominant.

ACK Error xảy ra khi:

• Node phát gửi frame
• Không có node nào kéo ACK bit xuống dominant

Các tình huống thường gặp:

• Chỉ có một node duy nhất trên bus
• Các node khác đang ở trạng thái Bus-Off
• Bitrate hoặc timing giữa các node không khớp

ACK Error không nhất thiết là lỗi dữ liệu, nhưng là dấu hiệu rất quan trọng cho thấy mạng CAN đang không có node phản hồi hợp lệ.

Tổng kết: Nhờ việc kết hợp nhiều loại lỗi (Bit, Stuff, CRC, Form, ACK), CAN có khả năng phát hiện lỗi cực kỳ mạnh, giúp hệ thống điều khiển duy trì tính ổn định và an toàn, ngay cả trong môi trường công nghiệp nhiều nhiễu.

 2. Error Frame & cơ chế báo lỗi trong CAN

Một điểm khác biệt rất quan trọng của CAN so với nhiều giao thức truyền thông khác là: bất kỳ node nào phát hiện lỗi đều có quyền ngay lập tức thông báo lỗi cho toàn mạng. Cơ chế này được thực hiện thông qua Error Frame.

Error Frame giúp CAN:

• Dừng ngay frame lỗi đang truyền
• Ngăn không cho dữ liệu sai được sử dụng
• Buộc frame phải được gửi lại

2.1 Error Frame là gì?

Error Frame là một frame đặc biệt, không mang dữ liệu ứng dụng, được phát ra khi một node CAN phát hiện bất kỳ lỗi nào (Bit Error, Stuff Error, CRC Error, Form Error, ACK Error…).

Khác với Data Frame, Error Frame không tuân theo cơ chế arbitration. Nó được thiết kế để phá vỡ frame hiện tại càng nhanh càng tốt.

Ngay khi Error Frame xuất hiện:

• Frame đang truyền trở nên không hợp lệ
• Tất cả các node đều loại bỏ frame đó
• Bus trở về trạng thái rỗi để chuẩn bị truyền lại

2.2 Cấu trúc của Error Frame

Một Error Frame trong CAN gồm 2 phần chính:

• Error Flag – báo hiệu lỗi
• Error Delimiter – kết thúc Error Frame

2.2.1 Error Flag

Error Flag là phần quan trọng nhất của Error Frame. Nó tồn tại dưới hai dạng, tùy vào trạng thái của node:

• Active Error Flag: 6 bit dominant liên tiếp
• Passive Error Flag: 6 bit recessive liên tiếp

Trong điều kiện bình thường, hầu hết các node đều phát Active Error Flag, vì dominant bit sẽ ngay lập tức áp đảo bus và khiến tất cả các node khác nhận ra có lỗi.

2.2.2 Error Delimiter

Sau Error Flag là Error Delimiter, gồm 8 bit recessive liên tiếp, đánh dấu kết thúc Error Frame và chuẩn bị cho bus quay lại trạng thái idle.

2.3 Active Error Frame và Passive Error Frame

CAN phân biệt rất rõ giữa node “lỗi nhẹ” và node “lỗi nhiều” thông qua hai loại Error Frame.

Active Error Frame

• Gồm 6 bit dominant
• Phá vỡ frame ngay lập tức
• Cho thấy node vẫn đang “hoạt động bình thường”

Passive Error Frame

• Gồm 6 bit recessive
• Ít ảnh hưởng hơn tới bus
• Cho thấy node đã gặp nhiều lỗi trước đó

Việc chuyển từ Active sang Passive không phải ngẫu nhiên, mà dựa trên bộ đếm lỗi (sẽ phân tích chi tiết ở mục sau).

2.4 Ví dụ minh họa cơ chế Error Frame

Ví dụ thực tế:

• Node A đang gửi một Data Frame
• Node B phát hiện CRC Error do nhiễu
• Ngay tại bit phát hiện lỗi, Node B phát Error Frame
• Tất cả các node thấy 6 bit dominant bất thường → loại bỏ frame
• Node A sẽ gửi lại frame sau khi bus rỗi

Nhờ vậy:

• Dữ liệu sai không bao giờ được sử dụng
• Lỗi được cô lập ngay tức thì
• Hệ thống vẫn tiếp tục hoạt động ổn định

2.5 Vì sao Error Frame là cơ chế cốt lõi của CAN?

Error Frame chính là nền tảng giúp CAN trở thành giao thức lý tưởng cho các hệ thống điều khiển an toàn:

• Phát hiện lỗi phân tán – node nào phát hiện cũng được báo lỗi
• Phản ứng tức thì – lỗi được xử lý ngay trong frame
• Không cần trung tâm giám sát
• Đảm bảo tính toàn vẹn dữ liệu tuyệt đối

Chính nhờ Error Frame, CAN có thể hoạt động ổn định trong môi trường: nhiễu cao, rung động mạnh, yêu cầu thời gian thực như ô tô, robot, dây chuyền sản xuất và hệ thống an toàn.

3. Error Counter (TEC / REC) & cách CAN đánh giá “mức độ lỗi” của node

Không giống nhiều giao thức chỉ đơn giản là “có lỗi hay không”, CAN sử dụng một cơ chế rất thông minh để định lượng mức độ lỗi của từng node. Cơ chế đó chính là Error Counter.

Mỗi node CAN luôn duy trì hai bộ đếm lỗi độc lập:

• TEC (Transmit Error Counter) – bộ đếm lỗi khi truyền
• REC (Receive Error Counter) – bộ đếm lỗi khi nhận

Dựa vào giá trị của hai bộ đếm này, CAN sẽ quyết định node đang ở trạng thái: Error Active, Error Passive hay Bus-Off.

3.1 TEC – Transmit Error Counter

TEC phản ánh mức độ “lỗi” của node khi node đóng vai trò là thiết bị phát.

TEC sẽ tăng khi:

• Node gửi frame nhưng phát hiện Bit Error
• Node gửi frame nhưng nhận CRC Error
• Frame gửi không được ACK (ACK Error)

TEC sẽ giảm khi:

• Node gửi frame thành công
• Frame được ACK hợp lệ bởi các node khác

👉 Điều này giúp CAN phân biệt:

• Node “thỉnh thoảng lỗi”
• Node “liên tục gây lỗi cho toàn mạng”

3.2 REC – Receive Error Counter

REC phản ánh mức độ lỗi của node khi node đóng vai trò là thiết bị nhận.

REC sẽ tăng khi:

• Node nhận frame bị CRC Error
• Node phát hiện Stuff Error
• Node phát hiện Form Error

REC sẽ giảm khi:

• Node nhận frame hợp lệ
• Frame được xử lý đúng định dạng

👉 Nhờ REC, CAN có thể phát hiện:

• Node bị nhiễu
• Node có timing sai
• Node có phần cứng hoặc transceiver lỗi

3.3 Cách Error Counter tăng và giảm

CAN không tăng Error Counter một cách tùy tiện, mà theo các quy tắc rất rõ ràng:

• Mỗi lỗi nghiêm trọng làm TEC hoặc REC tăng nhanh
• Mỗi frame hợp lệ làm Error Counter giảm từ từ

Ví dụ điển hình:

• Gửi frame lỗi → TEC tăng mạnh
• Gửi frame thành công → TEC giảm chậm

Cơ chế này đảm bảo:

• Lỗi lặp lại sẽ bị “phạt nặng”
• Lỗi ngẫu nhiên không làm node bị loại quá sớm

3.4 Ngưỡng Error Counter & trạng thái node

CAN sử dụng các ngưỡng Error Counter để đánh giá tình trạng hoạt động của node:

3.5 Ví dụ minh họa quá trình tăng Error Counter

Ví dụ thực tế:

• Node A cấu hình bitrate sai
• Gửi frame → các node khác không ACK
• TEC của Node A tăng nhanh
• Node A chuyển sang trạng thái Error Passive
• Tiếp tục lỗi → TEC đạt 256
• Node A bị Bus-Off và ngừng truyền hoàn toàn

Nhờ vậy:

• Node lỗi không làm sập toàn mạng
• Các node còn lại vẫn hoạt động ổn định

3.6 Vì sao Error Counter giúp CAN cực kỳ ổn định?

Error Counter biến CAN thành một mạng “tự đánh giá – tự bảo vệ”:

• Node tốt → được ưu tiên hoạt động
• Node lỗi nhẹ → được cảnh báo
• Node lỗi nặng → tự động bị cô lập

Cơ chế này đặc biệt quan trọng trong:

• Ô tô & hệ thống an toàn
• Robot & servo drive
• Dây chuyền sản xuất yêu cầu thời gian thực

👉 Đây chính là lý do CAN được đánh giá là một trong những giao thức bus ổn định và an toàn nhất trong công nghiệp.

 4. Error Active – Error Passive – Bus-Off: Cách CAN tự bảo vệ mạng

Một trong những điểm làm nên sự “đáng tin cậy” của CAN là khả năng tự đánh giá trạng thái của từng node và tự cô lập node lỗi khi cần thiết.

Dựa vào giá trị của TEC và REC, mỗi node CAN sẽ luôn nằm trong một trong ba trạng thái:

• Error Active – hoạt động bình thường
• Error Passive – hạn chế ảnh hưởng đến bus
• Bus-Off – bị tách hoàn toàn khỏi bus

4.1 Trạng thái Error Active – Hoạt động bình thường

Error Active là trạng thái mặc định của mọi node CAN khi hệ thống khởi động.

Điều kiện:

• TEC < 128
• REC < 128

Đặc điểm của node ở trạng thái Error Active:

• Được quyền truyền và nhận frame bình thường
• Có thể tham gia arbitration đầy đủ
• Phát Active Error Frame khi phát hiện lỗi

Active Error Frame sử dụng bit dominant, nên có khả năng ngắt ngay frame lỗi trên bus.

👉 Điều này giúp lỗi được phát hiện sớm và không lan rộng sang các frame khác.

Ví dụ:

• Node mới khởi động
• Wiring đúng, timing đúng
• Frame truyền/nhận ổn định

→ Node luôn duy trì trạng thái Error Active.

4.2 Trạng thái Error Passive – Node bị “cảnh cáo”

Khi một node gặp lỗi lặp lại nhiều lần, CAN sẽ đưa node đó vào trạng thái Error Passive.

Điều kiện chuyển sang Error Passive: TEC ≥ 128 hoặc REC ≥ 128

Đặc điểm của node Error Passive:

• Vẫn được phép truyền và nhận frame
• Không được phá vỡ bus mạnh mẽ
• Chỉ phát Passive Error Frame

Passive Error Frame sử dụng bit recessive, nên không chiếm quyền điều khiển bus.

👉 Mục tiêu của trạng thái này:

• Cho node tiếp tục tồn tại
• Nhưng giảm ảnh hưởng đến toàn mạng

Ví dụ thực tế:

• Node có bitrate hơi lệch
• Thỉnh thoảng lỗi CRC
• REC tăng dần > 128

→ Node bị chuyển sang Error Passive nhưng mạng CAN vẫn chạy ổn định.

4.3 Trạng thái Bus-Off – Node bị loại khỏi mạng

Bus-Off là trạng thái nghiêm trọng nhất trong CAN.

Điều kiện: TEC ≥ 256

Khi node rơi vào Bus-Off:

• Ngừng hoàn toàn việc truyền frame
• Không tham gia arbitration
• Không phát error frame
• Về cơ bản: node bị “ngắt kết nối logic”

👉 Mục tiêu của Bus-Off:

• Bảo vệ bus CAN
• Ngăn node lỗi phá hỏng toàn hệ thống

Ví dụ rất phổ biến:

• Node cấu hình bitrate sai hoàn toàn
• Gửi frame → không ai ACK
• TEC tăng nhanh
• Đạt 256 → Bus-Off

→ Node bị loại, các node khác vẫn hoạt động bình thường.

4.4 Sơ đồ chuyển đổi trạng thái Error

Quá trình chuyển đổi trạng thái của một node CAN:

• Error Active → Error Passive → Bus-Off

Chiều ngược lại (phục hồi):

• Bus-Off → Error Passive → Error Active

Quá trình phục hồi không tự động ngay lập tức mà phải tuân theo quy tắc nghiêm ngặt (có thể do firmware hoặc người vận hành quyết định).

4.5 Vì sao CAN không “sập mạng” khi có node lỗi?

Nhờ ba trạng thái này, CAN:

• Không để node lỗi chiếm bus lâu dài
• Không để lỗi lan rộng
• Tự động cô lập phần tử gây hại

So với nhiều giao thức khác:

• CAN không cần reset toàn mạng
• Không phụ thuộc vào thiết bị trung tâm
• Rất phù hợp cho hệ thống thời gian thực

👉 Đây chính là lý do CAN được tin dùng trong ô tô, robot, servo drive và các hệ thống an toàn cao.

5. Phục hồi Bus-Off – Tự động hay Thủ công? (Best Practice ngoài hiện trường)

Khi một node CAN rơi vào trạng thái Bus-Off, nó sẽ ngừng hoàn toàn việc truyền dữ liệu.

Vấn đề quan trọng đặt ra là:

Làm thế nào để node quay trở lại mạng CAN mà không gây nguy hiểm hoặc làm sập hệ thống?

CAN không ép buộc một cách phục hồi duy nhất, mà để nhà sản xuất và người thiết kế hệ thống lựa chọn.

5.1 Bản chất của phục hồi Bus-Off

Theo chuẩn CAN, khi một node đạt TEC ≥ 256:

• Node bị đưa vào Bus-Off
• Node phải ngừng truyền ngay lập tức

Chuẩn CAN không cho phép node tự ý quay lại bus ngay lập tức, vì:

• Node đó có khả năng cấu hình sai
• Hoặc lỗi vật lý chưa được khắc phục

👉 Do đó, việc phục hồi Bus-Off luôn phải đi kèm điều kiện an toàn.

5.2 Phục hồi Bus-Off tự động (Automatic Recovery)

Với phương pháp này, node CAN sẽ tự động quay lại hoạt động sau một khoảng thời gian thỏa điều kiện.

Cơ chế phổ biến:

• Node phải quan sát bus ở trạng thái Idle
• Liên tục trong 128 × 11 bit time
• Không phát hiện lỗi mới

Sau đó:

• TEC được reset về 0
• Node quay lại trạng thái Error Active

Ưu điểm:

• Tự động hoàn toàn
• Không cần can thiệp con người
• Phù hợp hệ thống đơn giản

Nhược điểm (rất quan trọng):

• Nếu lỗi chưa được sửa → node lại Bus-Off
• Có thể gây vòng lặp Bus-Off liên tục
• Không phù hợp hệ thống an toàn cao

Ví dụ ngoài hiện trường:

• Mạng CAN nhỏ
• Chỉ vài node
• Lỗi do nhiễu tạm thời

→ Auto Recovery có thể chấp nhận được.

5.3 Phục hồi Bus-Off thủ công (Manual / Controlled Recovery)

Với phương pháp này, node chỉ được phép quay lại bus khi phần mềm hoặc người vận hành cho phép.

Các cách phục hồi thủ công phổ biến:

• Reset CAN controller bằng phần mềm
• Reset thiết bị (power cycle)
• Chờ lệnh từ PLC / CPU trung tâm

Trong nhiều hệ thống công nghiệp:

• Bus-Off được coi là fault nghiêm trọng
• Phải log lỗi
• Phải xác nhận nguyên nhân

Ưu điểm:

• An toàn cao
• Tránh node lỗi phá bus liên tục
• Dễ chẩn đoán sự cố

Nhược điểm:

• Cần logic phần mềm
• Có thể gây gián đoạn vận hành

Ví dụ thực tế:

• PLC điều khiển servo drive qua CAN
• Drive Bus-Off → PLC dừng máy
• Kỹ thuật viên kiểm tra wiring / bitrate
• Sau đó reset drive → cho phép chạy lại

5.4 So sánh phục hồi Bus-Off: Tự động vs Thủ công

5.5 Kinh nghiệm phục hồi Bus-Off 

Khuyến nghị thực tế:

• ❌ Không để auto recovery vô điều kiện
• ✅ Log sự kiện Bus-Off
• ✅ Kiểm tra bitrate & termination trước khi reset
• ✅ Áp dụng reset có kiểm soát

Trong hệ thống quan trọng:

• Bus-Off → dừng máy an toàn
• Chẩn đoán nguyên nhân
• Chỉ cho phép node quay lại khi xác nhận OK

👉 Đây là cách các hệ thống CAN trong ô tô, robot, servo drive đảm bảo an toàn và ổn định lâu dài.

Kết Luận – Khi CAN “tự bảo vệ” chính mình

Các bạn thân mến, điều làm CAN trở nên khác biệt so với nhiều giao thức truyền thông khác không chỉ nằm ở tốc độ hay cấu trúc frame, mà nằm ở cách nó đối diện với lỗi.

CAN được thiết kế với cơ chế phát hiện lỗi đa tầng, từ mức bit, mức frame cho đến toàn bộ mạng. Mỗi node không chỉ truyền dữ liệu, mà còn liên tục tự kiểm tra và tự đánh giá độ tin cậy của chính mình thông qua Error Counter.

Khi một node trở nên “không còn đáng tin”, CAN không cố gắng sửa sai bằng mọi giá. Thay vào đó, nó chủ động loại node đó khỏi bus bằng trạng thái Bus-Off để bảo vệ toàn bộ hệ thống.

Vì vậy, Bus-Off không phải là lỗi thiết kế, mà là một cơ chế an toàn được tính toán rất kỹ: hy sinh một node để giữ cho mạng CAN còn lại tiếp tục hoạt động ổn định.

Khi hiểu rõ Error Handling trong CAN, người kỹ sư không còn “sợ lỗi”, mà bắt đầu:

• Thiết kế hệ thống CAN ổn định hơn
• Chẩn đoán và debug sự cố dễ dàng hơn
• Vận hành mạng CAN bền bỉ ngoài hiện trường

Nhưng xử lý lỗi chỉ là một nửa câu chuyện.

Nửa còn lại nằm ở việc: làm thế nào để CAN không tạo ra lỗi ngay từ đầu?

Trong Phần tiếp theo, chúng ta sẽ đi sâu vào những nguyên nhân vật lý gây lỗi CAN ngoài thực tế: từ dây dẫn, termination, topology, cho đến cách đo và debug tín hiệu CAN bằng oscilloscope và CAN analyzer.

👉 Hiểu đúng – đo đúng – sửa đúng, đó là cách một hệ thống CAN đi từ “chạy được” đến “chạy bền”.