Communication Protocol Archives - บริษัท ฮันนี่คอร์ปอเรชั่น จำกัด

Sep72026 by contentNo Comments

Modbus จาก RTU สู่ TCP: คู่มือ How-to ปลดล็อกข้อมูลอุปกรณ์อุตสาหกรรมจากสายอนุกรมสู่ระบบ IIoT

Article

บทนำ: โปรโตคอลอายุ 47 ปีที่ยังไม่ยอมตาย ปี 1979 บริษัท Modicon พัฒนาโปรโตคอลสื่อสารสำหรับ PLC ของตัวเอง ไม่มีใครคิดว่ามันจะกลายเป็นมาตรฐานโลก แต่วันนี้ Modbus กลายเป็นโปรโตคอลที่ฝังตัวอยู่ในอุปกรณ์อุตสาหกรรมมากที่สุดตัวหนึ่งของโลก ทั้งมิเตอร์ไฟฟ้า อินเวอร์เตอร์ ตู้แช่ เครื่องชั่งน้ำหนัก และเซ็นเซอร์ประเภทต่างๆ ปัจจุบันดูแลโดย Modbus Organization โดยเวอร์ชันล่าสุดของข้อกำหนดแอปพลิเคชันคือ V1.1b3 (เม.ย. 2012) เหตุผลที่มันอยู่ได้ทนเพราะความเรียบง่าย: โครงสร้างข้อความมีแค่ Address + Function Code + Data + CRC ไม่มีความซับซ้อนของโปรโตคอลยุคใหม่ อุปกรณ์ราคาประหยัดทำได้ง่าย วิศวกรเข้าใจได้เร็ว และที่สำคัญ เปิดใช้ฟรี ไม่มีลิขสิทธิ์ จึงกลายเป็นภาษากลางที่ทุกแบรนด์ต้องพูดให้ได้ โครงสร้างการเชื่อมต่อ RS-485 ระหว่างอุปกรณ์ 2 ตัว — ฐานล่างของ Modbus RTU ยุคแรกๆ (ที่มา: Wikimedia Commons) ปัญหาจริงในโรงงาน: เกาะข้อมูลบนสายอนุกรม สถานการณ์คลาสสิกที่ทีมงาน Honey Corporation เจอบ่อยในโรงงานไทย: ลูกค้ามี อุปกรณ์ Modbus RTU บน RS-485 เป็นสิบตัว กระจายอยู่ทั่วโรงงาน แต่ละตัวอ่านค่าได้เฉพาะเวลาช่างเอาโน้ตบุ๊กไปเสียบหน้างาน หรือไม่ก็ต้องมี HMI ประจำจุดที่คอย poll ข้อมูลแบบจุดต่อจุด อยากดูยอดรวมแบบเรียลไทม์บนมือถือ ทำไม่ได้เพราะข้อมูลถูกขังอยู่ใน "เกาะ" ของสายอนุกรมแต่ละเส้น ทางออกที่ถูกที่สุดและได้ผลที่สุดในทางปฏิบัติคือ ย้าย Modbus ขึ้นไปวิ่งบนเครือข่าย TCP/IP แล้วรวมศูนย์การเข้าถึงผ่าน Gateway ตัวเดียว ซึ่งเป็นงานที่ทีมงานของเราทำเป็นประจำ ทั้งในงานเก็บข้อมูลตู้แช่อุตสาหกรรมและงานผูกมิเตอร์พลังงานเข้าระบบ Monitoring ของโรงงาน แผงควบคุม PLC — จุดรวมสัญญาณที่ Modbus ยังคงเป็นภาษากลางในการสื่อสารกับอุปกรณ์ฟิลด์ (ที่มา: Wikimedia Commons) เข้าใจโครงสร้างก่อนแปลงร่าง: RTU vs ASCII vs TCP ประเด็น Modbus RTU Modbus ASCII Modbus TCP ตัวกลาง RS-485 / RS-232 RS-485 / RS-232 Ethernet / TCP-IP รูปแบบข้อมูล Binary + CRC-16 ASCII…

Sep72026 by contentNo Comments

Single Pair Ethernet (10BASE-T1L): เทคโนโลยีสาย 2 เส้นที่ส่ง Ethernet ไกล 1 กิโลเมตร ถึงเซ็นเซอร์ระดับฟิลด์

Article

ทำไมสาย 2 เส้นกำลังเปลี่ยนโฉมหน้าการเดินสายในโรงงาน ตลอดสิบกว่าปีที่ผ่านมา วิศวกรอุตสาหกรรมต้องออกแบบเครือข่ายโรงงานโดยยอมรับข้อจำกัดข้อหนึ่งเสมอมา นั่นคือ Ethernet แบบดั้งเดิมวิ่งได้แค่ 100 เมตร พอเกินระยะนั้นต้องพึ่งสายไฟเบอร์ พร้อมสวิตช์ขยายสัญญาณ หรือไม่ก็ยอมใช้ระบบ analog 4–20 mA ที่ส่งได้ทีละค่า เก็บข้อมูลการวินิจฉัยไม่ได้เลย Single Pair Ethernet (SPE) คือคำตอบที่ IEEE ตอบโจทย์นี้ด้วยมาตรฐาน IEEE 802.3cg-2019 ซึ่งกำหนด Ethernet ความเร็ว 10 Mbps บนสาย twisted pair เพียง คู่เดียว (2 เส้น) โดยตัวที่โรงงานอุตสาหกรรมสนใจมากที่สุดคือ 10BASE-T1L ที่รองรับระยะส่งสูงสุดถึง 1,000 เมตร — ยาวกว่า Ethernet ปกติถึง 10 เท่า และยังส่งไฟเลี้ยงผ่านสายเดียวกันได้ด้วยเทคโนโลยี PoDL (Power over Data Lines) ที่จ่ายไฟให้อุปกรณ์ปลายทางได้สูงสุดราว 50 วัตต์ Media Converter สำหรับ SPE รุ่น 10BASE-T1S — อุปกรณ์แปลงสัญญาณ Ethernet คู่เดียวให้เชื่อมกับคอมพิวเตอร์ผ่าน USB (ที่มา: Wikimedia Commons) จุดเปลี่ยนสำคัญ: จาก Fieldbus Island สู่เครือข่ายเดียวจากเซ็นเซอร์ถึงคลาวด์ ปัญหาใหญ่ที่สุดของโรงงานไทยหลายแห่งไม่ใช่การขาดเซ็นเซอร์ แต่คือ เซ็นเซอร์ที่มีอยู่พูดภาษาต่างกันหมด ยกตัวอย่างโรงงานอาหารทั่วไป: มิเตอร์วัดการไหลใช้ระบบ 4–20 mA, เซ็นเซอร์วัดอุณหภูมิตู้แช่ใช้ RS-485, สายพานผลิตวิ่งบน Industrial Ethernet แล้วพอจะเก็บข้อมูลขึ้นคลาวด์ ต้องผ่าน Protocol Gateway หลายชั้น ข้อมูลหายและหน่วงตามทาง SPE ตัดปัญหานี้ด้วยการทำให้ เซ็นเซอร์ระดับฟิลด์เข้าสู่โลก Ethernet ได้โดยตรง เพราะสายคู่เดียวราคาถูกกว่าสาย 4 คู่แบบ Cat 5e/6 ทั้งยังเบากว่า เดินผ่านท่อร้อยสายเดิมที่มีขนาดเล็กได้ ทีมงาน Honey Corporation มีประสบการณ์ติดตั้งระบบเก็บข้อมูล IoT ในโรงงานอุตสาหกรรมที่เจอข้อจำกัดแบบเดียวกันนี้ เช่น งานติดตั้งระบบ Monitoring ตู้แช่แข็งที่ต้องดึงสัญญาณจากจุดที่อยู่ไกลจากตู้คอนโทรลกลาง การวางแผนชนิดสายและระยะทางตั้งแต่ต้นจึงเป็นงานที่เราให้ความสำคัญเป็นพิเศษ โครงสร้างสาย Twisted Pair แบบ F-UTP — SPE ใช้เพียงคู่สายเดียวในลักษณะนี้ ลดปริมาณทองแดงและน้ำหนักสายได้มาก (ที่มา: Wikimedia…

Aug102026 by contentNo Comments

WirelessHART (IEC 62591): เครือข่ายไร้สายแบบ Self-Healing Mesh ที่ Process Industry เลือกใช้ — วิเคราะห์ทำไมมาตรฐานนี้ยังคงความสำคัญในยุค IIoT

Article

บทความวิเคราะห์ — มุมมองจาก Honey Corporation เกี่ยวกับ WirelessHART (IEC 62591) โปรโตคอลไร้สายสำหรับ Process Industry ที่ยังคงได้รับการเลือกใช้อย่างแพร่หลาย แม้ในยุคที่เทคโนโลยี IIoT ทันสมัยกว่าก็ตาม ในอุตสาหกรรมกระบวนการผลิต (Process Industry) เช่น โรงกลั่นน้ำมัน โรงงานเคมี และโรงไฟฟ้า การติดตั้งสายเคเบิลไปยังเครื่องมือวัดทุกจุดบนท่อขนาดใหญ่เป็นงานที่ยากและมีต้นทุนสูง WirelessHART (IEC 62591) คือคำตอบที่กลายเป็นมาตรฐานสากลตั้งแต่ปี 2010 และยังคงถูกใช้งานอย่างแพร่หลายในปัจจุบัน ท่ามกลางการมาของเทคโนโลยี IIoT รุ่นใหม่ ภาพประกอบ: เครือข่าย Mesh ของ WirelessHART ในโรงงานกระบวนการผลิต — แต่ละ Field Device ทำหน้าที่เป็นทั้งผู้ส่งและกระจายสัญญาณ (ภาพจาก Unsplash) WirelessHART คืออะไร? WirelessHART เป็นมาตรฐานการสื่อสารไร้สายสำหรับ Field Instruments ที่พัฒนาจาก HART Communication Protocol (Highway Addressable Remote Transducer) ซึ่งเป็นโปรโตคอลแบบมีสายที่ใช้กันอย่างแพร่หลายใน Process Industry มานานกว่า 30 ปี โดยใช้เครือข่ายไร้สายบนคลื่นความถี่ 2.4 GHz IEEE 802.15.4 ร่วมกับสถาปัตยกรรม Self-Organizing Mesh Network มาตรฐานนี้ได้รับการรับรองใน IEC 62591 Edition 2.0 (2016) และกลายเป็นมาตรฐานสากลสำหรับ Industrial Wireless Communication ในงาน Process Automation หัวใจของ WirelessHART: Self-Healing Mesh Network ความแตกต่างสำคัญระหว่าง WirelessHART กับระบบไร้สายแบบ Star Topology ทั่วไป (เช่น Wi-Fi) คือสถาปัตยกรรม Mesh Network ที่ทุก Field Device ทำหน้าที่เป็นทั้งผู้ส่งข้อมูล และกระจายสัญญาณให้อุปกรณ์อื่น: Multi-hop Routing: ข้อมูลสามารถกระโดดผ่านอุปกรณ์หลายตัวเพื่อไปถึง Gateway — ไม่จำเป็นต้องอยู่ใกล้ Gateway Self-Healing: หากเส้นทางหนึ่งถูกบดบังด้วยอุปกรณ์เคลื่อนที่หรือสิ่งกีดขวาง ระบบจะหาเส้นทางใหม่อัตโนมัติภายในไม่กี่วินาที Redundant Paths: แต่ละอุปกรณ์มีเส้นทางสำรองหลายเส้นทาง — หาก Neighbor หนึ่งล้มเหลว อีกเส้นทางจะทำงานแทน Time-Synchronized: ทุกอุปกรณ์ซิงโครไนซ์เวลากันและสื่อสารใน Time…

Aug102026 by contentNo Comments

CoAP สำหรับ IIoT: โปรโตคอล RESTful บน UDP ที่ทำให้เซ็นเซอร์ตัวเล็กส่งข้อมูลได้อย่างประหยัดพลังงาน — Tutorial การใช้งานแบบ Step-by-Step

Article

บทความรูปแบบ Tutorial — เรียนรู้วิธีใช้ CoAP (Constrained Application Protocol) สำหรับเชื่อมต่ออุปกรณ์ IoT ที่มีทรัพยากรจำกัด ตั้งแต่หลักการไปจนถึงการใช้งานจริง เมื่อพูดถึงโปรโตคอลสำหรับ IIoT หลายคนนึกถึง MQTT ก่อนเป็นอันดับแรก แต่มีอีกโปรโตคอลหนึ่งที่ถูกออกแบบมาโดยเฉพาะสำหรับอุปกรณ์ที่มีข้อจำกัดด้านพลังงานและหน่วยความจำ — CoAP (Constrained Application Protocol) ซึ่งกำหนดโดย IETF ใน RFC 7252 CoAP เป็นโปรโตคอลแบบ RESTful Web Transfer ที่ทำงานบน UDP (ไม่ใช่ TCP เหมือน HTTP) ทำให้มี overhead ต่ำมาก เหมาะสำหรับไมโครคอนโทรลเลอร์และเซ็นเซอร์ที่ทำงานด้วยแบตเตอรี่ โดยเฉพาะในเครือข่าย 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks) ภาพประกอบ: อุปกรณ์ IoT ขนาดเล็กที่ใช้ CoAP สื่อสารผ่านเครือข่าย 6LoWPAN ด้วย UDP (ภาพจาก Unsplash) ทำไมต้อง CoAP แทน HTTP? HTTP ถูกออกแบบมาสำหรับคอมพิวเตอร์ที่มีทรัพยากรเพียบพร้อม แต่เซ็นเซอร์ IIoT จำนวนมากมี RAM เพียง 10–100 KB และทำงานบนเครือข่ายที่มี packet loss สูง CoAP จึงถูกสร้างขึ้นเพื่อแก้ปัญหาเหล่านี้: คุณสมบัติ CoAP HTTP Transport Layer UDP TCP Header Size 4 bytes (fixed) ~200–800 bytes Methods GET, POST, PUT, DELETE + Observe GET, POST, PUT, DELETE, PATCH Security DTLS (Datagram TLS) TLS/SSL Power Consumption ต่ำมาก (No TCP handshake) สูง (TCP 3-way handshake) Message Encoding Binary Text-based CoAP Message Format:…

Aug102026 by contentNo Comments

EtherCAT: เทคโนโลยี Real-Time Ethernet ที่ประมวลผล 1,000 I/O Points ใน 30 ไมโครวินาที — หัวใจของ Motion Control ในโรงงานยุค Industry 4.0

Article

ในโลกของระบบอัตโนมัติอุตสาหกรรม ความเร็วในการสื่อสารระหว่าง Controller กับเครื่องจักรคือตัวตัดสินว่าสายการผลิตจะทำงานได้แม่นยำและซิงโครไนซ์กันหรือไม่ EtherCAT (Ethernet for Control Automation Technology) คือเทคโนโลยี Real-Time Industrial Ethernet ที่พัฒนาโดย Beckhoff Automation และกลายเป็นมาตรฐานสากลใน IEC 61158 โดยสามารถประมวลผล 1,000 I/O points ในเวลาเพียง 30 ไมโครวินาที และสื่อสารกับ 100 servo axes ใน 100 ไมโครวินาที ด้วย jitter ต่ำกว่า 1 ไมโครวินาที ล่าสุดในเดือนเมษายน 2026 EtherCAT Technology Group รายงานว่าจำนวน EtherCAT nodes ทั่วโลกทะลุ 105.2 ล้าน nodes ซึ่งเป็นสถิติที่ทะลุ 100 ล้านครั้งแรก ยืนยันตำแหน่งผู้นำตลาด Real-Time Industrial Ethernet อย่างเด็ดขาด ภาพประกอบ: เครือข่าย EtherCAT เชื่อมต่อ Master Controller กับ Slave Nodes ในรูปแบบ Line/Ring Topology เพื่อความเร็วระดับไมโครวินาที (ภาพจาก Unsplash) หลักการทำงาน: "Processing on the Fly" สิ่งที่ทำให้ EtherCAT แตกต่างจาก Industrial Ethernet อื่นๆ คือหลักการ "Pass-Through Reading" หรือ "Processing on the Fly" แทนที่จะส่งแพ็กเก็ตแยกให้แต่ละ node อย่างในระบบแบบเดิม EtherCAT Master จะส่ง เฟรมเดียว ที่บรรจุข้อมูลสำหรับทุก node ออกไป เมื่อเฟรมวิ่งผ่านแต่ละ Slave node ฮาร์ดแวร์ของ node นั้นจะแยกข้อมูลที่ตั้งใจไว้ให้ตนเองและฝังข้อมูลตอบกลับลงในเฟรมเดียวกันทันที — โดยไม่ต้องรอให้เฟรมเดินทางไปถึงปลายสุดก่อน กระบวนการนี้เปรียบเสมือน "รถไฟสินค้า" ที่แต่ละสถานีโหลดและขนถ่ายสินค้าในขณะที่รถไฟวิ่งผ่าน โดยไม่ต้องจอด ทำให้แบนด์วิดท์ถูกใช้อย่างมีประสิทธิภาพสูงสุดโดยไม่เสียไปกับแพ็กเก็ตซ้ำซ้อน สถาปัตยกรรมและคุณสมบัติทางเทคนิค คุณสมบัติ EtherCAT Industrial Ethernet ทั่วไป Cycle Time 12.5 μs – 100 μs 1…

Aug22026 by contentNo Comments

TSN (Time-Sensitive Networking): ชุดมาตรฐาน IEEE 802.1 ที่ปฏิวัติ Ethernet ให้กลายเป็นเครือข่ายเรียลไทม์สำหรับโรงงานอัตโนมัติ

Article

TSN เปลี่ยน Ethernet มาตรฐานให้รองรับการสื่อสารแบบ Real-Time แบบกำหนดเวลา (ภาพประกอบ) TSN: มาตรฐาน IEEE 802.1 ที่ปฏิวัติ Ethernet ให้กลายเป็นเครือข่าย Real-Time สำหรับโรงงานอัตโนมัติ TSN (Time-Sensitive Networking) คือชุดมาตรฐานภายใต้ IEEE 802.1 ที่เพิ่มความสามารถด้าน Real-Time Deterministic Communication ให้กับ Ethernet มาตรฐาน ทำให้สามารถส่งข้อมูลที่ "ต้องถึงในเวลาที่กำหนดเท่านั้น" (deterministic latency) ได้อย่างแม่นยำในระดับไมโครวินาที ก่อนหน้า TSN ระบบอัตโนมัติที่ต้องการ Real-Time จำเป็นต้องใช้ Fieldbus หรือ Industrial Ethernet แบบ proprietary ซึ่งไม่สามารถทำงานร่วมกับเครือข่าย IT มาตรฐานได้ TSN มาแก้ปัญหานี้โดยให้ทั้ง IT และ OT ทำงานบน Ethernet เดียวกันได้ โดยที่ Real-Time traffic ยังคง latency ต่ำและ deterministic สถาปัตยกรรมหลักของ TSN: Time Synchronization + Scheduling TSN อาศัยพื้นฐานสำคัญสองอย่างที่ทำงานร่วมกัน: 1. Time Synchronization (IEEE 802.1AS) อุปกรณ์ทุกตัวในเครือข่ายต้องมีนาฬิกาที่ ตรงกันในระดับ sub-microsecond (±1 ไมโครวินาที) โดยใช้ gPTP (generalized Precision Time Protocol) ที่สืบทอดเวลาจาก Grandmaster Clock ไปยังทุก node ผ่านกระบวนการ clock synchronization แบบต่อเนื่อง ⚡ ความแม่นยำ: gPTP ใน TSN สามารถ sync เวลาแม่นยำถึง ±100 นาโนวินาทีในเครือข่าย LAN ซึ่งเทียบเท่ากับมาตรฐาน PTP (IEEE 1588) แต่ทำงานที่ Layer 2 โดยตรง 2. Time-Aware Scheduling (IEEE 802.1Qbv) เมื่อทุกอุปกรณ์มีเวลาตรงกัน ก็สามารถกำหนด TGATE (Time Gate) เพื่อสร้าง "ช่องเวลา" (Time Slot) สำหรับส่งข้อมูล…

Aug22026 by contentNo Comments

OPC UA: มาตรฐานกลางสำหรับการแลกเปลี่ยนข้อมูลอุตสาหกรรมที่ทำลายกำแพง Vendor Lock-in ในยุค Industry 4.0

Article

OPC UA เชื่อมข้อมูลระหว่างอุปกรณ์และระบบต่างผู้ผลิตในโรงงานอัตโนมัติ (ภาพประกอบ) OPC UA: มาตรฐานกลางที่ทำลายกำแพง Vendor Lock-in ในโรงงานอัตโนมัติ OPC UA (Open Platform Communications Unified Architecture) คือมาตรฐานเปิดสำหรับการแลกเปลี่ยนข้อมูลในระบบอัตโนมัติอุตสาหกรรม ที่พัฒนาโดย OPC Foundation เพื่อแก้ปัญหาใหญ่ที่สุดของวงการอุตสาหกรรม นั่นคือ Vendor Lock-in — การที่อุปกรณ์จากผู้ผลิตแต่ละรายใช้โปรโตคอลสื่อสารเฉพาะ ทำให้ไม่สามารถเชื่อมต่อกันได้ ในช่วงปลายปี 2025 OPC Foundation ได้ประกาศมาตรฐานใหม่ OPC UA FX (Field eXchange) ที่ออกแบบมาเพื่อการสื่อสารระดับ Field Device โดยตรง โดยไม่ต้องผ่าน Server ตัวกลาง ถือเป็นก้าวสำคัญที่จะเปลี่ยนโครงสร้างการสื่อสารในโรงงานจากแบบ Hierarchical (แบบเดิม) เป็น Peer-to-Peer ในอนาคตอันใกล้ สถาปัตยกรรม OPC UA: สองโหมดการทำงาน OPC UA รองรับการสื่อสารสองรูปแบบหลัก: 1. Client/Server Model (แบบดั้งเดิม) อุปกรณ์ Client ส่ง Request ไปยัง Server เพื่ออ่าน/เขียนข้อมูล ใช้ TCP เป็น transport โดย Session หนึ่งสามารถสร้าง Subscription สำหรับรับข้อมูลแบบ Monitored Item ได้ — เมื่อค่าเปลี่ยน Server จะส่ง Notification กลับมาอัตโนมัติ 2. PubSub Model (เพิ่มใน OPC UA Part 14) เหมือนกับ MQTT — Publisher ส่งข้อมูลไปยัง Message Broker หรือ Multicast ไปยัง Subscriber ที่สนใจ โดยไม่ต้องสร้าง Session ตรง เหมาะกับการส่งข้อมูล Telemetry จำนวนมากในเวลาเดียวกัน คุณสมบัติ Client/Server PubSub การเชื่อมต่อ Session-based (TCP) Connectionless (UDP/Multicast) Latency ~10-50 ms ~1-10 ms Scalability หลักร้อย-Security หลักหมื่น กรณีใช้งาน…

Aug22026 by contentNo Comments

MQTT สำหรับ IIoT: โปรโตคอล Pub/Sub ที่ขับเคลื่อนการสื่อสารข้อมูลเซ็นเซอร์หลายล้านตัวในโรงงานอัจฉริยะ

Article

ระบบเครือข่าย IIoT ที่ใช้ MQTT เชื่อมต่อเซ็นเซอร์และอุปกรณ์อุตสาหกรรม (ภาพประกอบ) MQTT: โปรโตคอล Pub/Sub ที่ขับเคลื่อนการสื่อสารเซ็นเซอร์หลายล้านตัวในโรงงานอัตโนมัติ MQTT (Message Queuing Telemetry Transport) เป็นโปรโตคอลสื่อสารแบบ lightweight ที่ OASIS กำหนดเป็นมาตรฐานเปิด โดยออกแบบมาเพื่อส่งข้อมูลจากอุปกรณ์ที่มีทรัพยากรจำกัด เช่น เซ็นเซอร์อุณหภูมิ มอเตอร์ หรือ PLC ในโรงงานอุตสาหกรรม ด้วยสถาปัตยกรรม Publish/Subscribe ที่แยกผู้ส่งและผู้รับออกจากกัน ทำให้ MQTT สามารถรองรับการเชื่อมต่ออุปกรณ์นับหมื่นพร้อมกันโดยใช้แบนด์วิดธ์ต่ำเพียง 2 bytes ต่อ header ในปี 2025-2026 MQTT ได้กลายเป็นโปรโตคอลหลักของระบบ IIoT ทั่วโลก โดยเวอร์ชันล่าสุด MQTT 5.0 เพิ่มความสามารถสำคัญ เช่น Reason Codes, Shared Subscriptions, Message Expiry และ Topic Aliases ที่ช่วยแก้ปัญหาด้าน reliability และ scalability ที่เวอร์ชัน 3.1.1 ไม่สามารถรองรับได้ สถาปัตยกรรม Publish/Subscribe: หัวใจของ MQTT ต่างจากโปรโตคอลแบบ Request/Response แบบเดิม MQTT ใช้รูปแบบ Pub/Sub ที่ผู้ส่ง (Publisher) ไม่จำเป็นต้องรู้ว่าผู้รับ (Subscriber) คือใคร ทุกอย่างผ่านศูนย์กลางที่เรียกว่า MQTT Broker ซึ่งทำหน้าที่กรองและส่งต่อข้อความตามหัวข้อ (Topic) ที่กำหนด ตัวอย่าง Topic ในโรงงานอุตสาหกรรม: factory/line-A/temperature/sensor-01 — อุณหภูมิจากเซ็นเซอร์ตัวที่ 1 ของสายการผลิต A factory/line-A/vibration/motor-03 — ค่าการสั่นสะเทือนของมอเตอร์ 3 factory/line-B/energy/meter-main — การใช้พลังงานของสายการผลิต B การใช้ Topic Hierarchy แบบนี้ ทำให้ Subscriber สามารถ subscribe เฉพาะข้อมูลที่ต้องการ เช่น factory/+/temperature/# เพื่อรับทุกค่าอุณหภูมิจากทุกสายการผลิต QoS (Quality of Service): การรับประกันการส่งมอบ MQTT กำหนดระดับ QoS 3 ระดับ เพื่อให้เลือกใช้ตามความสำคัญของข้อมูล: ระดับ QoS การรับประกัน Handshake กรณีใช้งานในโรงงาน…

Jul272026 by contentNo Comments

TSN (Time-Sensitive Networking): ชุดมาตรฐาน IEEE 802.1 ที่ปฏิวัติ Ethernet ให้กลายเป็นเครือข่ายเรียลไทม์สำหรับโรงงานอัตโนมัติ

Article

TSN (Time-Sensitive Networking) คือชุดมาตรฐานภายใต้ IEEE 802.1 ที่เพิ่มความสามารถด้าน Real-Time Deterministic Communication ให้กับ Ethernet มาตรฐาน ทำให้สามารถส่งข้อมูลที่ "ต้องถึงในเวลาที่กำหนดเท่านั้น" (Guaranteed Latency) ได้อย่างแม่นยำ ซึ่งเป็นพื้นฐานสำหรับการ รวมเครือข่าย OT และ IT เข้าด้วยกันบนโครงสร้างพื้นฐานเดียว ปัญหาที่ TSN มาแก้ ในโรงงานแบบดั้งเดิม เครือข่ายการควบคุม (OT) และเครือข่ายสารสนเทศ (IT) ถูกแยกออกจากกันโดยสมบูรณ์ เพราะ Ethernet มาตรฐานเป็นแบบ Best-Effort คือพยายามส่งให้ถึง แต่ไม่รับประกันเวลา ขณะที่ระบบควบคุมการเคลื่อนที่ต้องการ Latency ที่ แน่นอนและทำนายได้ (เช่น < 1 ms) จึงต้องใช้ Fieldbus เฉพาะที่แพงและไม่เข้ากันข้ามแบรนด์ TSN เปลี่ยน Ethernet ให้กลายเป็นเครือข่ายเดียวที่รองรับทั้งข้อมูล Real-Time Control (เช่น คำสั่งควบคุมมอเตอร์) และข้อมูล Best-Effort (เช่น อีเมล, Video Stream) พร้อมกันบนสายเคเบิลเส้นเดียวกัน องค์ประกอบหลักของ TSN 1. Time Synchronization (IEEE 802.1AS — gPTP) รากฐานของ TSN คือการที่อุปกรณ์ทุกตัวในเครือข่าย ต้องมีนาฬิกาที่ตรงกัน ภายในความคลาดเคลื่อน ±1 ไมโครวินาที (μs) โดยใช้โปรโตคอล gPTP (generalized Precision Time Protocol) ที่สืบทอดเวลาจาก Grandmaster ผ่านสวิตช์ทุกตัวแบบ Hop-by-Hop 2. Traffic Scheduling (IEEE 802.1Qbv — TAS) Time-Aware Shaper (TAS) แบ่งเวลาเป็น Cycle และกำหนด Gate เปิด-ปิดสำหรับแต่ละ Queue ในสวิตช์ ตัวอย่างเช่น: ช่วง 0–50 μs: เปิดเฉพาะ Critical Traffic (คำสั่งควบคุม) ช่วง 50–100 μs: เปิดให้ Best-Effort Traffic (ข้อมูลทั่วไป) ช่วง 100–125 μs: Reserve ไว้สำหรับ Management…

Jul272026 by contentNo Comments

OPC UA: มาตรฐานกลางสำหรับการแลกเปลี่ยนข้อมูลอุตสาหกรรมที่ทำลายกำแพง Vendor Lock-in ในยุค Industry 4.0

Article

OPC UA (Open Platform Communications Unified Architecture) เป็นมาตรฐานเปิดสำหรับการแลกเปลี่ยนข้อมูลในระบบอัตโนมัติอุตสาหกรรม ที่ถูกพัฒนาขึ้นเพื่อแก้ปัญหาใหญ่ที่สุดของวงการอุตสาหกรรม นั่นคือ Vendor Lock-in — ปัญหาที่ข้อมูลจาก PLC ของผู้ผลิตเครื่องจักรแต่ละรายใช้โปรโตคอลเฉพาะ ทำให้ไม่สามารถอ่านข้อมูลข้ามแบรนด์ได้โดยตรง ทำไมโลกอุตสาหกรรมต้องการ OPC UA? ในอดีต โรงงานหนึ่งอาจมีเครื่องจักรจากผู้ผลิต 5–10 ราย แต่ละรายใช้ Fieldbus หรือ Protocol เป็นของตัวเอง การดึงข้อมูลมารวมกันที่ SCADA หรือ MES จำเป็นต้องใช้ Protocol Converter หรือ Custom Driver เป็นสิบตัว OPC UA แก้ปัญหานี้ด้วยการกำหนด มาตรฐานกลางที่ทุกผู้ผลิตสามารถ Implement ได้โดยไม่ต้องจ่ายค่า License ใดๆ OPC UA = "ภาษากลาง" ของโรงงานอัตโนมัติ — เหมือน HTTP สำหรับเว็บ แต่สำหรับเครื่องจักรและอุปกรณ์อุตสาหกรรม ทุกอุปกรณ์ที่พูด OPC UA สามารถเข้าใจกันได้โดยตรง Information Model — หัวใจของ OPC UA สิ่งที่ทำให้ OPC UA แตกต่างจากโปรโตคอลอื่นคือ Information Model หรือโมเดลข้อมูลที่ไม่ได้ส่งเพียงค่าตัวเลขดิบ (เช่น 75.5) แต่ส่งพร้อม บริบท เช่น: ชื่อตัวแปร: Motor.Line1.Temperature หน่วย: องศาเซลเซียส (°C) ช่วงค่า: -40 ถึง 150°C คุณภาพของข้อมูล: Good / Bad / Uncertain เวลาที่อ่านค่า: Timestamp ระดับมิลลิวินาที โครงสร้างนี้เรียกว่า Address Space ที่จัดเก็บข้อมูลทั้งหมดในรูปแบบ Object-Oriented มี Method, Event และ Reference เชื่อมโยงกัน สองรูปแบบการสื่อสาร: Client/Server vs PubSub คุณสมบัติ Client/Server (Classic) PubSub (เพิ่มใน UA Part 14) โมเดล Client ขอ → Server ตอบ Publisher ส่ง →…