CAN bus ตอนที่ 1 ทฤษฎี CAN

4 ปีที่ผ่านมา

โดย เจ้าของร้าน

CAN bus เป็นหนึ่งในรูปแบบการสื่อสารผ่านสายที่ออกแบบมาสำหรับงานด้านยานพาหนะ (Automotive) ต่าง ๆ เช่น รถยนต์ รถไถ รถยก รถแม็คโคร รถไฟฟ้า เครื่องบิน เป็นต้น เป็นรูปแบบการสื่อสารที่เป็นมาตรฐาน ถูกรับรองโดยองค์กรระดับโลก ถูกใช้งานจริงในรถยนต์สมัยใหม่ และภายหลังงานด้านอุตสาหกรรม (Industry) ได้เริ่มนำ CAN มาใช้งานมากขึ้น ในบทความนี้จะมาแนะนำทฤษฎีเกี่ยวกับ CAN bus ทั้งประวัติการพัฒนา และหลักการทำงานเชิงวิศวกรรม

CAN bus คืออะไร ?

Controller Area Network หรือ CAN bus เป็นมาตรฐานการสื่อสารผ่านสายที่ออกแบบมาให้อุปกรณ์ใช้สื่อสารกับอุปกรณ์ โดยเริ่มต้นใช้อยู่ในรถยนต์เป็นหลัก ในรถยนต์แต่ละระบบจะมีส่วนควบคุม (ไมโครคอนโทรลเลอร์ หรือ กล่อง ECU) เป็นของตัวเอง เช่น เครื่องเล่นเพลง ระบบที่ปัดน้ำฝน ระบบถุงลมนิรภัย ระบบเครื่องยนต์ และระบบอื่น ๆ กว่า 70 ระบบ แต่ละระบบล้วนมีส่วนควบคุม (กล่อง ECU) เป็นของตัวเอง เพื่อให้รถยนต์สามารถทำงานได้ ทุกระบบจึงจำเป็นจะต้องสื่อสารกัน และการสื่อสารกันก็ทำผ่าน CAN bus นั่นเอง

CAN bus มีข้อได้เปรียบ และแตกต่างกับการสื่อสารผ่านสายแบบอื่น ๆ ดังนี้

ทุกอุปกรณ์บนบัสคือตัวแม่ (Multi-master)

ปกติการสื่อสารผ่านสายที่เชื่อมต่ออุปกรณ์หลาย ๆ ตัวเข้าด้วยกันบนบัสเดียวกัน เช่น Modbus RTU , I²C , SPI จะต้องมีตัวแม่ (Master) เพียงตัวเดียว และตัวที่เหลือเป็นตัวลูก (Slave) โดยตัวลูกจะส่งข้อมูลได้ก็ต่อเมื่อตัวแม่ร้องขอเท่านั้น สำหรับ CAN bus อุปกรณ์ทุกตัวคือตัวแม่ การส่งข้อมูลจะส่งให้ใคร เมื่อไรก็ได้ ไม่มีใครเป็นตัวควบคุม แก้ปัญหาหากตัวแม่พังเสียหาย ระบบจะไม่สามารถใช้งานได้ทั้งหมด (บน CAN bus หากมีอุปกรณ์ใดเสียหาย อุปกรณ์นั้น ๆ จะแตะตัวเองออก อุปกรณ์อื่น ๆ ยังสื่อสารกันได้ปกติ)

ทุกอุปกรณ์ได้รับข้อมูล แต่เลือกรับข้อมูลได้ (Multi-cast)

การส่งข้อมูลบน CAN bus คือการส่งที่ทุกอุปกรณ์ได้รับข้อมูลทั้งหมด (broadcast) ทั้งนี้หากอุปกรณ์ใดต้องการเลือกรับเฉพาะบางข้อมูล (Multi-cast) ก็สามารถทำได้เช่นกัน

มีการตรวจจับความผิดพลาดและแจ้งเตือน (Error Detection and Signalling)

ทุกอุปกรณ์บน CAN bus จะมีการตรวจสอบข้อมูลที่วิ่งอยู่ในบัสเสนอ หากมีอุปกรณ์ใดตรวจพบความผิดพลาดของการส่งข้อมูล อุปกรณ์นั้นจะส่งข้อมูลแจ้งเตือนทันที

มีการจัดลำดับความสำคัญของข้อมูล (Message Priorities)

หากเกิดเหตุการณ์ที่มีอุปกรณ์ใด ๆ ส่งข้อมูลพร้อมกันขึ้น ข้อมูลที่มีความสำคัญมากกว่าจะได้รับสิทธิ์ในการส่งก่อน ส่วนข้อมูลที่มีความสำคัญน้อยกว่าจะได้โอกาศส่งใหม่ในภายหลัง

ประวัติของ CAN bus

ในยุคที่รถยนต์ไม่ได้มีระบบไฟฟ้ามากมายนัก ระบบต่าง ๆ ถูกเชื่อมต่อกันด้วยสายแบบจุดต่อจุด และใช้ระบบเดียวในการควบคุมรถยนต์ทั้งคัน เมื่อรถยนต์ถูกพัฒนาให้มีระบบความบันเทิง ระบบแอร์ และระบบไฟฟ้าอื่น ๆ มากขึ้น การใช้สายแบบจุดต่อจุดยากต่อการผลิต การซ่อมบำรุง และสิ้นเปลืองค่าใช้จ่าย ในปี 1983 บริษัทบ๊อช (Bosch - เป็นที่รู้จักในไทยในฐานะผู้ผลิตเครื่องมือช่างชื่อดัง) ได้เริ่มต้นพัฒนา CAN bus ขึ้นมา เพื่อแก้ปัญหาการเชื่อมต่อสายแบบจุดต่อจุด จากนั้นในปี 1991 ตัว CAN bus จึงถูกนำไปใช้จริงในรถยนต์เมอร์เซเดส-เบนซ์ ซีรีย์ W140 เป็นต้นมา ในปีเดียวกันนี้ บริษัท Bosch ยังได้เผยแพร่มาตรฐาน CAN 2.0 เพื่อให้รถยนต์ทุกยี่ห้อสามารถนำ CAN bus ไปใช้ได้อีกด้วย

องค์กร International Organization for Standardization หรือที่คุ้นหูกันคือ ISO ได้รับรองให้ CAN เป็นมาตรฐาน ISO 11898 ในปี 1993 ส่งผลให้ผู้ผลิตรถยนต์ ผู้ผลิตชิป และผู้ผลิตอุปกรณ์ที่เกี่ยวข้อง ได้ยึดมาตรฐานนี้ในการผลิตสินค้านับตั้งแต่นั้นเป็นต้นมา

เกิดความเปลี่ยนแปลงอีกครั้งในปี 2012 บริษัทบ๊อช ได้เผยแพร่ CAN FD 1.0 หรือ CAN with Flexible Data-Rate ทำให้ CAN bus สามารถเลือกความเร็ว (Data Rate) ในการสื่อสารได้ องค์กร ISO รับรองให้ CAN FD เป็นมาตรฐาน ISO 11898-1 ในปี 2015, ปีถัดมา (2016) CAN bus ที่มีความเร็วในการสื่อสาร (Data Rate) 5 Mbit/s ถูกรับรองให้เป็นมาตรฐาน ISO 11898-2

ต่อไปนี้จะอ้างอิงมาตรฐาน ISO 11898-1/ISO 11898-2 เป็นหลัก เนื่องจากเป็นมาตรฐานที่ใช้ในปัจจุบัน

CAN ในฐานะ Physical Layer

Physical Layer หรือ ชั้นกายภาพ เป็นข้อกำหนดการเชื่อมต่อสาย , CAN bus ใช้สายในการเชื่อมต่อระหว่างส่วนควบคุม (ECU หรือไมโครคอนโทรลเลอร์หรือ CAN Device) ด้วยสาย 2 เส้น เชื่อมต่ออุปกรณ์ที่ต้องการสื่อสารทั้งหมดเข้าด้วยกัน (ดังรูปที่ 1) ประกอบด้วยสาย CAN High (CANH) และ CAN Low (CANL) ที่ปลายสายทั้ง 2 ด้าน ต่อตัวต้านทาน 120Ω (เรียกว่า Terminating Resistor) เพื่อ dampen overshoot for high drive lines and reduce signal noise

รูปที่ 1 การเชื่อมต่อระหว่างส่วนควบคุมด้วย CAN bus

สาย CANH และ CANL ทำงานแบบ differential wire คือใช้ความแตกต่างของแรงดันไฟฟ้าระหว่างสาย 2 เส้นในการรับ-ส่งข้อมูล โดยมีวัตถุประสงค์เพื่อลดสัญญาณรบกวน สัญญาณภายในสายประกอบด้วย 2 สถานะ คือ

สถานะ Dominant เกิดขึ้นเมื่อแรงดันของสาย CANH มากกว่าสาย CANL ซึ่งแปลเป็นสถานะส่งลอจิก 0
สถานะ Recessive เกิดขึ้นเมื่อแรงดันของสายเส้น CANH น้อยกว่าหรือเท่ากับ CANL แปลเป็นสถานะส่งลอจิก 1

จากรูปที่ 2 จะเห็นว่า ในสถานะ Dominant (ส่งลอจิก 0) แรงดันของสาย CANH มีค่าประมาณ 3.5V ส่วน CANL มีค่าประมาณ 1.5V ในสถานะ Recessive (ส่งลอจิก 1) แรงดันของสาย CANH และ CANL มีค่าเท่ากันคือ 2.5V สาย CANH และ CANL มีแรงดันแตกต่างกัน 0V

รูปที่ 2 แรงดันไฟฟ้าในสาย CAN High (CANH) และ CAN Low (CANL)

โหนด (Node)

โหนด (Node) หรืออุปกรณ์ CAN (CAN Device) หรือส่วนควบคุม (ECU) ภายในประกอบด้วย 2 ส่วน คือ

1) CAN controller

CAN controller เป็นวงจรไฟฟ้าที่ออกแบบมาสำหรับใช้ควบคุมการรับ-ส่งข้อมูลผ่าน CAN โดยเฉพาะ มักฝังมาภายในไมโครคอนโทรลเลอร์ที่สเปคสูง หรือถูกออกแบบมาเพื่องานด้าน Automotive โดยเฉพาะ ไมโครคอนโทรลเลอร์ที่ฝัง CAN controller มาในตัว เช่น ESP32 ATSAME51 เป็นต้น ไมโครคอนโทรลเลอร์ที่ไม่มี CAN controller สามารถต่อไอซี CAN controller ภายนอกเพิ่มได้ เช่น MCP2515 เป็นต้น

2) CAN Transceiver

CAN Transceiver ทำหน้าที่แปลงสัญญาณลอจิก 0 และ 1 แบบ TTL (ลอจิก 1 = 3.3V/5V, ลอจิก 0 = 0V) ให้เป็นสัญญาณเพื่อส่งออก CANH และ CANL โดย CAN Transceiver เป็นอุปกรณ์ที่ต้องต่อแยกออกมาจากตัวไมโครคอนโทรลเลอร์ ไอซี CAN Transceiver มีผลิตหลายบริษัท แต่ละบริษัทแต่ละรุ่นจะมีสเปคด้านความเร็วในการรับ-ส่งข้อมูล (Data Rate) ที่แตกต่างกัน และใช้แรงดันไฟเลี้ยงต่างกัน (มีรุ่นใช้ไฟเลี้ยง 5V กับรุ่นใช้ไฟเลี้ยง 3.3V) ตัวอย่างไอซี CAN Transceiver ได้แก่ SN65HVD232DR TJA1050 BD41041FJ-CE2 โดยส่วนใหญ่ ไอซี CAN Transceiver ตัวถังจะเป็น SOIC-8 มีขาที่ตรงกันทุกเบอร์ ดังนั้นจึงใช้แทนกันได้ทั้งหมด

รูปที่ 3 ส่วนประกอบของ CAN Node

การรับ-ส่งข้อมูลผ่าน CAN

การรับ-ส่งข้อมูลผ่าน CAN ใช้สิ่งที่เรียกว่า CAN frame และ 1 CAN frame หมายถึงการส่งข้อมูล 1 ครั้ง โดยCAN frame แบ่งเป็น 4 ชนิดดังนี้

Data frame – ใช้ส่งข้อมูลไปยังอุปกรณ์ CAN อื่น ๆ
Remote frame – ใช้ร้องขอข้อมูลจากอุปกรณ์ CAN อื่น ๆ
Error frame – ใช้แจ้งทุกอุปกรณ์ CAN ว่าพบความผิดพลาดขึ้นบนบัส
Overload frame

การใช้งานจริงมีเพียง Data frame และ Remote frame เท่านั้นที่ผู้ใช้สามารถเขียนโปรแกรมสั่งงานได้ ส่วน Error frame และ Overload frame ตัว CAN controller จะจัดการให้อัตโนมัติ

Data frame และ Remote frame มี 2 รูปแบบ คือ Standard Frame และ Extended Frame โดย Standard Frame มีโครงสร้างดังนี้

รูปที่ 4 โครงสร้าง Standard Frame, ที่มา csselectronics.com

SOF: Start of Frame (1 บิต) - ส่ง Dominant (ส่งลอจิก 0) เพื่อบอกให้ทุกอุปกรณ์บนบัสรับรู้ว่ากำลังจะมีการส่งข้อมูล
ID: Identifier (11 บิต สำหรับ Standard Frame) – หมายเลขเฉพาะของชุดข้อมูลนี้ โดยอาจกำหนดเป็นหมายเลขอุปกรณ์ หรือหมายเลขของข้อมูลที่ตั้งขึ้นมาเฉพาะก็ได้ โดยหมายเลขนี้จะเป็นตัวกำหนดความสำคัญของข้อมูลด้วย หากมีค่าน้อย หมายถึงมีความสำคัญมาก
RTR: Remote Transmission Request (1 บิต) – บิตกำหนดว่าเป็น Remote frame หรือไม่ ดังนี้
- RTR = Dominant (ลอจิก 0) หมายถึง ข้อมูลชุดนี้เป็น Data frame
- RTR = Recessive (ลอจิก 1) หมายถึง ข้อมูลชุดนี้เป็น Remote frame
Control (6 บิต) ประกอบไปด้วย
- IDE: Identifier extension bit (1 บิต) – ใช้ตรวจจับว่าเป็น Standard Frame หรือ Extended Frame
- Reserved (1 บิต) – สงวนบิตนี้ไว้สำหรับฟีเจอร์ในอนาคต มีค่าเป็น Dominant (ลอจิก 0) เสมอ
- DLC: Data Length Code (4 บิต) – แบ่งเป็น 2 กรณีดังนี้
  1. ถ้า RTR = Dominant (ลอจิก 0, Data frame) ใช้บอกความยาวของข้อมูลที่ส่ง
  2. ถ้า RTR = Recessive (ลอจิก 1, Remote frame) ใช้บอกความยาวของข้อมูลที่ร้องขอ
Data (0 ถึง 64 บิต หรือ 0 ถึง 8 ไบต์) – ข้อมูลที่ต้องการส่ง
CRC (16 บิต) – แบ่งดังนี้
- CRC (15 บิต)
- CRC delimiter (1 บิต) – มีค่าเป็น Recessive (ลอจิก 1) เสมอ
ACK (2 บิต) – แบ่งดังนี้
- ACK slot (1 บิต) – ฝั่งส่งจะปล่อยให้บัสเป็นสถานะ Recessive (ลอจิก 1) หากมีอุปกรณ์ใด ๆ ในบัสได้รับ และยืนยันว่าข้อมูลที่ส่งถูกต้อง บิตนี้จะถูกดึงเป็น Dominant (ลอจิก 0)
- ACK delimiter (1 บิต) – มีค่าเป็น Recessive (ลอจิก 1) เสมอ
EOF (7 บิต) – ใช้ส่งเพื่อบอกสิ้นสุด CAN frame

Extended Frame แตกต่างจาก Standard Frame ตรงที่ฟิลด์ ID มีความยาว 29 บิต และมีโครงสร้างอื่น ๆ ที่แตกต่างกันเล็กน้อย

การใช้งานจริง ฟิลด์ที่กำหนดค่าได้คือ ID, RTR, DLC และ Data ส่วนฟิลด์อื่น ๆ ตัว CAN controller จะจัดการให้อัตโนมัติ

ความเร็วในการรับ-ส่งข้อมูล

CAN เป็นโปรโตคอลแบบ Asynchronous ความเร็วในการรับ-ส่งข้อมูลถูกกำหนดโดย Data Rate หรือ Baudrate ซึ่งสามารถกำหนดได้ดังนี้

12,500 (12.5 kbit/s)
16,000 (16 kbit/s)
20,000 (20 kbit/s)
25,000 (25 kbit/s)
50,000 (50 kbit/s)
100,000 (100 kbit/s)
125,000 (125 kbit/s) – โดยปกติใช้ค่านี้
250,000 (250 kbit/s)
500,000 (500 kbit/s)
800,000 (800 kbit/s)
1,000,000 (1 Mbit/s)

อุปกรณ์บนบัส CAN จำเป็นจะต้องกำหนด Data Rate หรือ Baudrate ให้เท่ากันทุกตัว เพื่อให้สามาถรับ-ส่งข้อมูลได้ถูกต้อง

การเลือกรับข้อมูล (Acceptance Filter)

เนื่องจากการรับ-ส่งข้อมูลบน CAN เป็นแบบ Broadcast ดังนั้นจึงอาจมีข้อมูลที่ไม่ต้องการเข้ามาด้วย หากมีข้อมูลที่ไม่ต้องการเข้ามากเกินไปก็อาจจะทำให้แรม หรือพื้นที่เก็บข้อมูล CAN ขาเข้าเต็มได้ ดังนั้น CAN จึงมีสิ่งที่เรียกว่า Acceptance Filter เพื่อใช้กรองให้รับเฉพาะบาง CAN frame ที่มี ID ที่กำหนดไว้เท่านั้น

สถานะความผิดพลาดและตัวนับ (Error States and Counters)

CAN controller ของทุกโหนด (CAN Node) มีตัวนับที่ชื่อ Transmit Error Counter (TEC) และ Receive Error Counter (REC) ทำหน้าที่นับจำนวนความผิดพลาดที่เกิดจากการรับ-ส่งข้อมูลบนบัส โดยตัวนับแต่ละตัวใช้อ้างอิงสถานะความผิดพลาด (Error States) ดังนี้

Error Active คือ สถานะที่ตัวนับ TEC และ REC นับค่าได้น้อยกว่า 128 การรับ-ส่งข้อมูลยังเป็นไปตามปกติ แต่จะมีการส่ง Error frame ทุกครั้งที่พบความผิดพลาด
Error Passive คือ สถานะที่ตัวนับ TEC หรือ REC นับค่าได้มากกว่าหรือเท่ากับ 128 การรับ-ส่งข้อมูลยังเป็นไปตามปกติ แต่จะมีการส่ง Error frame ทุกครั้งที่พบความผิดพลาด
Bus-Off คือ สถานะที่ตัวนับ TEC นับค่าได้มากกว่าหรือเท่ากับ 256 ในสถานะนี้ CAN controller จะไม่รับ-ส่งข้อมูลบนบัสอีกต่อไป จนกว่าจะได้รับการกู้คืน