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

Jun82026 by contentNo Comments

WirelessHART (IEC 62591) vs Wi-SUN: เปรียบเทียบมาตรฐาน Wireless Mesh Network สำหรับ Process Automation

Article

ใน Process Automation ที่ต้องติดตั้งเซ็นเซอร์และ Actuator นับพันจุดทั่วโรงงานปิโตรเคมี การดึงสายแต่ละเส้นไม่เพียงแต่ เพิ่มต้นทุนการติดตั้งอย่างมหาศาล แต่ยังเพิ่มความเสี่ยงจากการชำรุดของสายเคเบิลในพื้นที่อันตราย (Hazardous Area) Wireless Mesh Network จึงกลายเป็นคำตอบที่อุตสาหกรรมกำลังมองหา โดย WirelessHART (IEC 62591) และ Wi-SUN เป็นสองมาตรฐานหลักที่น่าจับตามอง WirelessHART (IEC 62591): มาตรฐานจาก Process Automation WirelessHART คือ Extension ของ HART Protocol (Highway Addressable Remote Transducer) ที่ใช้กันอย่างแพร่หลายใน Process Industry มาตั้งแต่ปี 1980 โดยพัฒนาเป็นเวอร์ชันไร้สายในปี 2007 และได้รับมาตรฐาน IEC 62591 ในปี 2010: Frequency Band: 2.4 GHz ISM Band (IEEE 802.15.4) Topology: Mesh Network แบบ Self-Healing อัตโนมัติ Channel Hopping: กระโดดช่องสัญญาณ 16 ช่อง เพื่อหลีกเลี่ยง Interference Time-Synchronized — ทุก Node ซิงค์เวลากันภายใน ±1 ms Security: AES-128 Encryption ทั้ง Link Level และ Network Level Update Rate: 1 วินาทีถึงหลายนาที (ขึ้นอยู่กับจำนวน Node) จุดแข็งสำคัญของ WirelessHART คือ ความเข้ากันได้กับ HART EDDL ทำให้วิศวกรสามารถใช้ Tool เดิมในการ Configure และ Diagnose เซ็นเซอร์ไร้สายได้ทันที Wi-SUN (Wireless Smart Utility Network): มาตรฐานจาก Smart Grid Wi-SUN เริ่มต้นจากอุตสาหกรรม Smart Grid และ Smart Metering แต่กำลังขยายมาสู่ Industrial IoT โดยใช้มาตรฐาน IEEE 802.15.4g: Frequency Band: Sub-GHz…

Jun82026 by contentNo Comments

HTTP/3 และ QUIC Protocol สำหรับ Industrial IoT Cloud Connectivity: ทำไมโปรโตคอลรุ่นใหม่กำลังเปลี่ยนการเชื่อมต่อโรงงาน

Article

เมื่อโรงงานอุตสาหกรรมก้าวเข้าสู่ยุค Cloud-Connected Factory การเชื่อมต่อระหว่าง Edge Gateway กับ Cloud Platform กลายเป็นหัวใจสำคัญของระบบ IIoT ในขณะที่ HTTP/1.1 และ HTTP/2 ยังคงเป็นมาตรฐานหลัก HTTP/3 ที่ใช้ QUIC เป็น Transport Layer กำลังเข้ามาเป็นทางเลือกใหม่ที่แก้ปัญหา Head-of-Line Blocking และ Latency ที่รบกวนระบบอุตสาหกรรมมานาน HTTP วิวัฒนาการจาก Version 1 ถึง 3 โปรโตคอล HTTP ผ่านการพัฒนามากว่า 3 ทศวรรษ แต่ละเวอร์ชันแก้ปัญหาที่แตกต่างกัน: Version Transport Connection Model Head-of-Line Blocking HTTP/1.1 TCP 1 Request per Connection รุนแรงมาก HTTP/2 TCP Multiplexed Streams TCP Level HTTP/3 QUIC (UDP) Independent Streams ไม่มี QUIC คืออะไร? ทำไมถึงสำคัญสำหรับ IIoT QUIC (Quick UDP Internet Connections) เป็น Transport Protocol ที่พัฒนาโดย Google และถูกนำมาเป็นมาตรฐาน IETF ใน HTTP/3 จุดเปลี่ยนสำคัญคือการ เปลี่ยนจาก TCP เป็น UDP ซึ่งในบริบทของโรงงานอุตสาหกรรม หมายถึง: 0-RTT Connection — Connection ที่เคยสร้างไว้สามารถส่งข้อมูลได้ทันทีโดยไม่ต้อง Handshake ใหม่ ลด Latency ได้ 100-200 ms ต่อครั้ง Independent Stream Multiplexing — แต่ละ Stream เป็นอิสระ ถ้า Packet หายใน Stream หนึ่ง ไม่ส่งผลต่อ Stream อื่น Built-in Encryption — TLS 1.3 ฝังอยู่ใน QUIC เอง ไม่ต้องตั้งค่าแยก Connection Migration —…

Jun82026 by contentNo Comments

SPI และ I2C Protocol สำหรับ Embedded IoT: โปรโตคอลสื่อสารระยะสั้นที่ขับเคลื่อน Sensor Node ทุกตัว

Article

ในโลกของ Industrial IoT ที่เต็มไปด้วยเทคโนโลยีไร้สายขั้นสูงอย่าง 5G, LoRaWAN หรือ NB-IoT หลายคนอาจลืมไปว่า ทุก Sensor Node บนโลกใบนี้ล้วนพึ่งพาโปรโตคอลสื่อสารระยะสั้น อย่าง SPI (Serial Peripheral Interface) และ I2C (Inter-Integrated Circuit) ในการส่งข้อมูลจากเซ็นเซอร์ไปยัง Microcontroller ก่อนที่ข้อมูลจะถูกส่งต่อไปยัง Cloud หรือ Edge Gateway SPI คืออะไร? สถาปัตยกรรมแบบ Full-Duplex SPI เป็นโปรโตคอลสื่อสารแบบ Synchronous Serial ที่พัฒนาโดย Motorola ในปี 1980 ทำงานแบบ Full-Duplex ส่งและรับข้อมูลพร้อมกันได้ ด้วยสถาปัตยกรรม Master-Slave โดยใช้สายสัญญาณ 4 เส้น: SCLK (Serial Clock) — สัญญาณ Clock ควบคุมจังหวะการส่งข้อมูล MOSI (Master Out Slave In) — ข้อมูลจาก Master ไป Slave MISO (Master In Slave Out) — ข้อมูลจาก Slave ไป Master CS/SS (Chip Select) — เลือก Slave ที่ต้องการสื่อสาร จุดเด่นของ SPI คือความเร็วสูงมาก สามารถทำงานที่ สูงสุดถึง 60 MHz ขึ้นอยู่กับฮาร์ดแวร์ ทำให้เหมาะกับอุปกรณ์ที่ต้องการ Transfer Rate สูง เช่น ADC ความละเอียดสูง, SD Card, Display Module และ Flash Memory I2C คืออะไร? สถาปัตยกรรมแบบ 2-Wire I2C พัฒนาโดย Philips (ปัจจุบันคือ NXP) ในปี 1982 ใช้สายสัญญาณเพียง 2 เส้น ทำให้ประหยัด Pin บน Microcontroller อย่างมาก: SDA (Serial Data) — สายข้อมูลแบบ Bidirectional…

May312026 by contentNo Comments

Energy Harvesting สำหรับ IIoT Sensor: เทคโนโลยีเก็บพลังงานจากสิ่งแวดล้อมขับเคลื่อนเซ็นเซอร์ไร้สาย

Article

Energy Harvesting คืออะไร? จากพลังงานสิ่งแวดล้อมสู่เซ็นเซอร์ IoT ไร้สาย Energy Harvesting (หรือ Energy Scavenging) คือเทคโนโลยี เก็บพลังงานจากสิ่งแวดล้อม เช่น ความร้อน, แสงสว่าง, การสั่นสะเทือน, คลื่นวิทยุ มาแปลงเป็นไฟฟ้าสำหรับขับเคลื่อนเซ็นเซอร์และอุปกรณ์ IoT ขนาดเล็ก โดยไม่ต้องพึ่งพาแบตเตอรี่หรือสายไฟ ในบริบทของ IIoT ภาคอุตสาหกรรม การติดตั้งเซ็นเซอร์หลายร้อยหลายพันจุดบนเครื่องจักร ท่อ, ถังเก็บ, โครงสร้าง มักเจอปัญหา "ยากที่จะดึงสายไฟไปถึง" หรือ "เปลี่ยนแบตเตอรี่ไม่ไหว" Energy Harvesting จึงเป็นคำตอบที่ทำให้เซ็นเซอร์เหล่านี้ Self-Powered ทำงานได้นานหลายปีโดยไม่ต้องดูแล ⚡ พลังงานที่เก็บได้จากสิ่งแวด้อม: ในโรงงานอุตสาหกรรมทั่วไป พลังงานจากความร้อนเหลือทิ้ง (Waste Heat) มีมากถึง 20–50% ของพลังงานที่ป้อนเข้า หากเก็บเพียงส่วนเล็กน้อยก็เพียงพอขับเคลื่อนเซ็นเซอร์ IIoT หลายพันตัว แหล่งพลังงาน 4 ประเภทที่เก็บได้ในโรงงาน 1. Thermal Energy (พลังงานความร้อน) ใช้ Thermoelectric Generator (TEG) ทำงานตามหลัก Seebeck Effect — เมื่อมีความต่างอุณหภูมิระหว่างสองด้านของวัสดุเพียง 10–30°C ก็สามารถผลิตไฟฟ้าได้ 10–500 μW/cm² ในโรงงานพบ Heat Source ได้ทั่วไป: ท่อไอน้ำ (150–300°C), เตาอบ (200–500°C), Motor Housing (60–90°C) 2. Vibration Energy (พลังงานการสั่นสะเทือน) ใช้ Piezoelectric Harvester แปลงการสั่นของเครื่องจักรเป็นไฟฟ้า เครื่องจักรอุตสาหกรรมส่วนใหญ่สั่นที่ 50–200 Hz ด้วย Acceleration 0.1–1.0 g ซึ่งเพียงพอที่จะผลิตไฟฟ้าได้ 50–500 μW ต่อ Harvester หนึ่งตัว เหมาะสำหรับติดบน Motor, Pump, Compressor, CNC Machine 3. Solar/Light Energy (พลังงานแสง) ใช้ Miniature Solar Cell หรือ Indoor Photovoltaic Cell ขนาดเล็ก แม้ในโรงงานที่มีแสงจากหลอดไฟ LED หรือ Fluorescent เพียง 200–500 lux ก็สามารถผลิตไฟฟ้าได้ 5–20…

May312026 by contentNo Comments

Digital Supply Chain Twin: จำลองโซ่อุปทานเสมือนจริงด้วย Digital Twin เพื่อเพิ่มความยืดหยุ่นในการวางแผน

Article

Digital Supply Chain Twin คืออะไร? เกินกว่าแค่ Digital Twin ธรรมดา Digital Supply Chain Twin (DSCT) คือโมเดลจำลองเสมือนจริงของ โซ่อุปทานทั้งระบบ ตั้งแต่วัตถุดิบ กระบวนการผลิต คลังสินค้า การขนส่ง ไปจนถึงมือลูกค้า โดยมีข้อมูลจริงเชื่อมโยงแบบ Real-Time ผ่าน IoT Sensors, ERP Systems และ Logistics Platform ต่างจาก Digital Twin แบบดั้งเดิมที่มักจำลองเพียง เครื่องจักรเดี่ยว หรือ กระบวนการผลิตเดี่ยว DSCT ครอบคลุม End-to-End Supply Chain ทำให้สามารถจำลองสถานการณ์ What-If ได้ เช่น ถ้าท่าเรือปิด 7 วัน จะกระทบ Production Line วันไหน? ถ้า Supplier A ส่งมอบล่าช้า ควรสลับไปใช้ Supplier B หรือผลิตเอง? ตัวเลขสำคัญ: จากงานวิจัยของ Gartner พบว่าองค์กรที่นำ Digital Supply Chain Twin มาใช้ สามารถ ลดเวลาในการตัดสินใจลง 25-35% และ ลด Inventory Cost ได้ 10-20% เนื่องจากมีข้อมูลครบถ้วนและสามารถจำลองสถานการณ์ล่วงหน้าได้ สถาปัตยกรรม Digital Supply Chain Twin DSCT ประกอบด้วย 5 ชั้นหลักที่ทำงานร่วมกัน: Physical Layer — เซ็นเซอร์ IoT บนเครื่องจักร, RFID Tag บนวัตถุดิบ, GPS Tracker บนรถขนส่ง, Beacon ในคลังสินค้า Data Integration Layer — เชื่อม ERP, MES, WMS, TMS ผ่าน API Gateway โดยใช้ OPC UA หรือ REST API Digital Model Layer — สร้างโมเดล 3D + Data…

May312026 by contentNo Comments

Demand Response สำหรับโรงงานอุตสาหกรรม: ใช้ IoT จัดการโหลดไฟฟ้าอัจฉริยะลดต้นทุนพลังงาน

Article

Demand Response คืออะไร? ทำไมโรงงานอุตสาหกรรมต้องรู้ Demand Response (DR) คือกลยุทธ์จัดการการใช้ไฟฟ้าแบบ ปรับโหลดตามสัญญาณตลาด แทนการเพิ่มกำลังผลิตไฟฟ้า โดยผู้ใช้ไฟฟ้าในภาคอุตสาหกรรมจะลดหรือเลื่อนการใช้ไฟฟ้าในช่วง Peak Demand ออกไป เพื่อรับสิทธิประโยชน์ทั้งด้านค่าไฟที่ลดลงและค่าตอบแทนจากการเข้าร่วมโปรแกรม DR ในประเทศไทย การผลิตไฟฟ้าสูงสุด (Peak Demand) มักเกิดขึ้นในช่วง 13:00–15:00 น. ของวันทำงาน ซึ่งเป็นช่วงที่อุณหภูมิสูงและระบบทำความเย็นทำงานเต็มกำลัง หากโรงงานสามารถ Shift Load ออกจากช่วงเวลานี้ได้ จะส่งผลดีต่อทั้งต้นทุนพลังงานและเสถียรภาพของระบบไฟฟ้าโดยรวม สถาปัตยกรรมระบบ Demand Response ด้วย IoT การนำ Demand Response มาใช้ในโรงงานอุตสาหกรรม ต้องอาศัยโครงสร้าง IoT ที่ประกอบด้วย 4 ชั้นหลัก: Perception Layer — Smart Meter, CT Sensor, Power Quality Analyzer วัดการใช้ไฟฟ้าแบบ Real-Time ทุก 1–15 นาที Edge Layer — Edge Gateway ประมวลผลข้อมูลที่ต้นทาง ตัดสินใจ Load Shedding อัตโนมัติตามกฎที่ตั้งไว้ Platform Layer — Energy Management System (EMS) รวบรวมข้อมูลทุก Meter วิเคราะห์ Load Profile และพยากรณ์ความต้องการไฟฟ้า Application Layer — Dashboard แสดงผลแบบ Real-Time, Alert แจ้งเตือนเมื่อใกล้ถึง Peak Threshold พร้อม Automated Load Control 💡 ความสำคัญ: จากข้อมูลการไฟฟ้าส่วนภูมิภาค (PEA) พบว่าอุตสาหกรรมไทยใช้ไฟฟ้าประมาณ 47% ของไฟฟ้าทั้งประเทศ หากโรงงานลด Peak Demand ได้เพียง 10–15% ในช่วง Critical Period จะช่วยลดภาระระบบไฟฟ้าได้อย่างมีนัยสำคัญ กลยุทธ์ Demand Response ที่โรงงานสามารถใช้ได้ 1. Load Shifting — เลื่อนเวลาใช้ไฟ ย้ายกระบวนการผลิตที่ใช้พลังงานสูง เช่น เตาอบ, เครื่องอัดอัตโนมัติ, ระบบทำความเย็นขนาดใหญ่ ไปทำงานในช่วง Off-Peak (23:00–06:00 น.)…

May292026 by contentNo Comments

Industrial Router และ Edge Gateway: โครงสร้างเครือข่ายที่เชื่อมโยง Smart Factory ยุคใหม่

Article

📊 Market Insight 2026: ตลาด Industrial Router ทั่วโลกมีมูลค่ากว่า 3 พันล้านเหรียญสหรัฐ และคาดว่าจะเติบโตต่อเนื่องถึงปี 2031 ขับเคลื่อนด้วยความต้องการ Operational Efficiency และ Data-Driven Decision Making ในโรงงานอุตสาหกรรม Industrial Router คืออะไร? ทำไมโรงงานต้องใช้ Industrial Router หรือ Industrial Gateway คืออุปกรณ์เครือข่ายที่ออกแบบมาสำหรับสภาพแวดล้อมอุตสาหกรรมโดยเฉพาะ ทำหน้าที่เชื่อมต่ออุปกรณ์ IoT, PLC, Sensor และเครื่องจักรต่างๆ ภายในโรงงานเข้ากับระบบ IT และ Cloud Platform ต่างจาก Router ทั่วไปตรงที่ Industrial Router ต้องทนสภาพแวดล้อมที่รุนแรง เช่น อุณหภูมิสูง (-40°C ถึง +75°C), ความสั่นสะเทือน, ฝุ่น, ความชื้น และสัญญาณรบกวนทางแม่เหล็กไฟฟ้า (EMI) ที่พบได้ทั่วไปในโรงงานอุตสาหกรรม Industrial Router vs Consumer Router คุณสมบัติ Consumer Router Industrial Router Operating Temp 0°C ถึง 40°C -40°C ถึง +75°C MTBF ~50,000 ชั่วโมง 200,000+ ชั่วโมง Power Input AC 220V เท่านั้น DC 12-48V, Redundant Power DIN Rail Mount ไม่รองรับ รองรับ ✓ Protocol Support TCP/IP, WiFi Modbus, OPC UA, MQTT, Profinet, EtherCAT VPN / Security พื้นฐาน IPSec, WireGuard, Firewall, IEC 62443 Cellular (4G/5G) บางรุ่น Built-in 4G LTE / 5G, Dual SIM ประเภทของ Industrial Router / Gateway 1.…

May272026 by contentNo Comments

DCS vs SCADA: วิเคราะห์เชิงลึกว่าระบบควบคุมแบบไหนเหมาะกับโรงงานคุณ

Article

ในโลกของระบบควบคุมอุตสาหกรรม DCS (Distributed Control System) และ SCADA (Supervisory Control and Data Acquisition) ถือเป็น 2 ระบบหลักที่ขับเคลื่อนการทำงานของโรงงานทั่วโลก แม้ทั้งสองจะมีจุดประสงค์คล้ายกันคือ "ควบคุมและติดตามกระบวนการผลิต" แต่สถาปัตยกรรม ขีดความสามารถ และกรณีนำไปใช้งานจริง กลับต่างกันอย่างมีนัยสำคัญ บทความนี้จะเจาะลึกทุกมิติเพื่อให้วิศวกรและผู้บริหารโรงงานตัดสินใจได้อย่างถูกต้อง SCADA คืออะไร? สถาปัตยกรรมแบบไหน? SCADA เป็นระบบควบคุมแบบรวมศูนย์ (Centralized) ออกแบบมาเพื่อ Monitor และ Control กระบวนการที่กระจายตัวในพื้นที่กว้าง (Wide-Area) สถาปัตยกรรมหลักประกอบด้วย: MTU (Master Terminal Unit) — ศูนย์ควบคุมกลาง ทำหน้าที่เก็บข้อมูล, แสดงผล HMI และส่งคำสั่งควบคุม RTU (Remote Terminal Unit) — หน่วยรวบรวมข้อมูลจาก Field Instrument ที่กระจายอยู่ตามจุดต่างๆ Communication Network — เครือข่ายเชื่อมโยง MTU กับ RTU อาจใช้ Radio, Satellite, Fiber Optic หรือ Cellular HMI/SCADA Software — ซอฟต์แวร์แสดงผลและควบคุม ทำงานบน Server ณ ห้องควบคุมกลาง SCADA เน้น การเก็บข้อมูล (Data Acquisition) และ การควบคุมระยะไกล (Supervisory Control) มากกว่าการควบคุมแบบ Closed-Loop แบบต่อเนื่อง ตัวอย่างการใช้งาน: ระบบท่อส่งน้ำมัน, ระบบผลิตไฟฟ้า, ระบบจราจรอัจฉริยะ, ระบบกระจายก๊าซธรรมชาติ DCS คืออะไร? สถาปัตยกรรมแบบไหน? DCS เป็นระบบควบคุมแบบกระจาย (Decentralized) ที่ออกแบบมาเพื่อ ควบคุมกระบวนการผลิตแบบต่อเนื่อง (Continuous Process) ในพื้นที่เฉพาะจุด สถาปัตยกรรมหลักประกอบด้วย: Controller แบบกระจาย — ควบคุม Process Loop ย่อยๆ แยกกันอิสระ แต่เชื่อมโยงผ่าน Communication Bus High-Speed Communication Bus — เชื่อม Controller ทุกตัวเข้าด้วยกันด้วยความเร็วสูง (Redundant Pair) Operator Station — หน้าจอควบคุมหลายจุด แสดงผลแบบ…

May272026 by contentNo Comments

Web-Based HMI vs Traditional HMI: ไหนเหมาะกับโรงงานอุตสาหกรรมยุค Industry 4.0

Article

ในยุค Industry 4.0 ที่โรงงานอุตสาหกรรมกำลังเปลี่ยนผ่านสู่ Smart Factory Human-Machine Interface (HMI) หรือหน้าจอควบคุมเครื่องจักร ถือเป็นจุดเชื่อมต่อสำคัญระหว่างพนักงานกับระบบอัตโนมัติ ในอดีต HMI แบบดั้งเดิม (Traditional HMI) คือหน้าจอสัมผัสติดตั้งบนแผงควบคุม (Panel) แต่ปัจจุบัน Web-Based HMI กำลังเข้ามาเปลี่ยนรูปแบบการทำงานอย่างมาก Traditional HMI คืออะไร? Traditional HMI หรือ HMI แบบดั้งเดิม คือระบบหน้าจอสัมผัสหรือ Touch Panel ที่ติดตั้งอยู่บนแผงควบคุมหน้าเครื่องจักรโดยตรง ทำงานร่วมกับ PLC ผ่านโปรโตคอลอุตสาหกรรม เช่น Modbus TCP, Profinet, หรือ Ethernet/IP ซอฟต์แวร์ HMI ที่นิยมใช้จะรันบนระบบปฏิบัติการเฉพาะ (Proprietary OS) หรือ Windows Embedded ข้อดีหลัก: ตอบสนอง Real-Time ดีเยี่ยม หน่วงเวลาต่ำ (< 10 ms) เชื่อมต่อกับ PLC ได้โดยตรง ทำงานได้แม้เครือข่ายขัดข้อง เพราะสื่อสารผ่านสาย Cable โดยตรง ข้อจำกัด: ไม่สามารถเข้าถึงได้จากที่อื่น ต้องยืนหน้าเครื่องจึงจะควบคุมได้ การอัพเดท Software ต้องทำที่เครื่อง ซื้อ-ขายเป็นระบบปิด (Vendor Lock-in) และ Scalability จำกัด Web-Based HMI คืออะไร? Web-Based HMI ใช้เทคโนโลยี Web มาตรฐาน (HTML5, CSS, JavaScript) ทำงานบน Web Browser ทั้ง Chrome, Firefox, Safari หรือ Edge ผู้ใช้งานสามารถเข้าถึงหน้าจอควบคุมผ่าน Tablet, Smartphone หรือ Computer ได้จากทุกที่ที่มีเครือข่าย โดยข้อมูลจะส่งผ่าน OPC UA, MQTT, หรือ REST API ข้อดีหลัก: เข้าถึงได้จากทุกอุปกรณ์ (Cross-Platform) ไม่ต้องติดตั้ง Software เพิ่มเติม Remote Monitoring & Control สะดวก อัพเดทผ่าน Server กลางได้ และผสานกับระบบ Cloud และ Edge Computing…

May252026 by contentNo Comments

CoAP (Constrained Application Protocol) สำหรับ IIoT: โปรโตคอลว่ายน้ำหนักเบาสำหรับอุปกรณ์ IoT ขนาดเล็ก

Article

CoAP คืออะไร? โปรโตคอลที่ออกแบบมาเพื่ออุปกรณ์ Constrained ในโลกของ Industrial IoT อุปกรณ์จำนวนมากยังคงใช้ไมโครคอนโทรลเลอร์ขนาดเล็กที่มี RAM เพียง 10-100 KB และ Flash Memory ไม่เกิน 250 KB อุปกรณ์เหล่านี้ไม่สามารถรัน HTTP/TCP stack ที่หนักและซับซ้อนได้ CoAP (Constrained Application Protocol) จึงถูกพัฒนาขึ้นโดย IETF (RFC 7252) เพื่อเป็นโปรโตคอลระดับแอปพลิเคชันสำหรับอุปกรณ์ประเภทนี้โดยเฉพาะ CoAP ทำงานบน UDP แทน TCP ทำให้ overhead ต่ำกว่า HTTP อย่างมีนัยสำคัญ — packet header ของ CoAP มีขนาดเพียง 4 bytes เทียบกับ HTTP header ที่อาจมีขนาดหลายร้อย bytes แต่กระนั้น CoAP ยังคงรักษาโมเดล Request-Response ที่คุ้นเคย พร้อมรองรับ RESTful interaction เช่น GET, POST, PUT, DELETE เหมือน HTTP 💡 ข้อควรรู้: CoAP ไม่ได้มาแทนที่ MQTT แต่มาเติมเต็มช่องว่างที่ MQTT ทำไม่ได้ — โดยเฉพาะกรณีที่ต้องการ Request-Response pattern, Resource Discovery และการทำงานแบบ Multicast ในเครือข่ายท้องถิ่น สถาปัตยกรรม CoAP: เลเยอร์ที่ทำให้มันพิเศษ CoAP ถูกออกแบบมาด้วยสถาปัตยกรรมแบบ 2 เลเยอร์: Message Layer — จัดการการส่ง-รับข้อมูลผ่าน UDP รองรับ Confirmable (CON) และ Non-confirmable (NON) message, พร้อม mechanism ตรวจสอบ duplicate message โดยอัตโนมัติ Request/Response Layer — ทำงานเหนือ Message Layer จัดการ RESTful method (GET, POST, PUT, DELETE) และ response code ที่คล้าย HTTP (2.05…