MQTT กับ HTTP กับ Modbus TCP กับ OPC UA สำหรับเกตเวย์ IoT อุตสาหกรรม

ข้อมูลเซ็นเซอร์เดียวกันสามารถส่งข้อมูลได้หลายวิธี

เซ็นเซอร์ไม่ได้กำหนดคลาวด์สุดท้ายหรือโปรโตคอล SCADA โดยทั่วไปจะใช้ RS485 Modbus RTU ที่เลเยอร์ฟิลด์ ในขณะที่เกตเวย์แปลหรือแพ็กเกจข้อมูลนั้นใหม่สำหรับเลเยอร์แอปพลิเคชัน โปรโตคอลอัปสตรีมที่ถูกต้องขึ้นอยู่กับผู้ที่เริ่มการสื่อสาร สถานที่จัดเก็บข้อมูล คำสั่งจะต้องส่งคืนไปยังอุปกรณ์หรือไม่ และซอฟต์แวร์ใดที่ลูกค้าใช้งานอยู่แล้ว

MQTT: ดีที่สุดสำหรับระบบเผยแพร่/สมัครสมาชิกบนคลาวด์

MQTT แยกผู้ส่งและผู้รับผ่านนายหน้า เกตเวย์จะเผยแพร่ข้อมูลเซ็นเซอร์ไปยังหัวข้อ ในขณะที่แอปพลิเคชันหนึ่งรายการขึ้นไปสมัครรับหัวข้อนั้น สิ่งนี้มีประโยชน์สำหรับไซต์การตรวจสอบแบบกระจาย เนื่องจากเกตเวย์ไม่จำเป็นต้องรู้ข้อมูลผู้บริโภคขั้นสุดท้ายทุกคน

โดยทั่วไปการกำหนดค่า MQTT ที่ถูกต้องจะรวมถึงที่อยู่ของนายหน้า พอร์ต รหัสไคลเอ็นต์ การตรวจสอบสิทธิ์ และกฎของหัวข้อ ข้อผิดพลาดทั่วไปคือการสันนิษฐานว่า “อุปกรณ์ออนไลน์” หมายถึง “ข้อมูลมาถึง” สถานะการเชื่อมต่อ MQTT เพียงพิสูจน์ว่ามีการสร้างเซสชันแล้ว เกตเวย์อาจยังคงเผยแพร่ไปยังหัวข้อที่ไม่ถูกต้อง เซิร์ฟเวอร์อาจสมัครรับหัวข้ออื่น หรือเลเยอร์การรับเซ็นเซอร์อาจไม่มีข้อมูลที่ถูกต้อง

เผยแพร่และสมัครสมาชิกจะต้องไม่สับสน

หัวข้อเผยแพร่คือจุดที่อุปกรณ์ส่งการวัดและส่งข้อมูลทางไกล โดยปกติแล้วหัวข้อสมัครสมาชิกจะใช้สำหรับคำสั่งหรือข้อความที่ส่งจากแพลตฟอร์มกลับไปยังอุปกรณ์ หากเซิร์ฟเวอร์ต้องการรับการวัด ก็ควรสมัครรับหัวข้อการเผยแพร่เกตเวย์ การใช้หัวข้อการเผยแพร่และสมัครสมาชิกเดียวกันสามารถสร้างการวนซ้ำที่ไม่ต้องการในการใช้งานบางอย่าง และไม่ควรถือว่าเป็นการกำหนดค่าเริ่มต้น

MQTTS และพอร์ต 8883

โดยทั่วไป MQTTS หมายถึง MQTT มากกว่า TLS พอร์ต 8883 เป็นพอร์ต TLS ทั่วไป แต่การใช้งานให้สำเร็จจะขึ้นอยู่กับหมายเลขพอร์ตมากกว่า ไลบรารี TLS, วิธีการตรวจสอบความถูกต้องของ CA, ใบรับรองเซิร์ฟเวอร์, ใบรับรองไคลเอ็นต์เสริม และเวอร์ชัน MQTT จะต้องเข้ากันได้ ในการทดสอบคลาวด์ของบุคคลที่สามจริง บางครั้งเกตเวย์สามารถเชื่อมต่อกับโบรกเกอร์ TLS รายหนึ่งได้ แต่จะล้มเหลวกับอีกตัวหนึ่งจนกว่าจะอัปเดตเฟิร์มแวร์

สำหรับโปรเจ็กต์ที่ใช้งานจริง ให้ทดสอบนายหน้า โหมดใบรับรอง และเฟิร์มแวร์ที่แน่นอนก่อนจัดส่งเป็นชุดจำนวนมาก ใบรับรองควรมาจากหรือตรงกับเซิร์ฟเวอร์ของลูกค้าหรือแพลตฟอร์มคลาวด์ ไม่ใช่ไฟล์ทั่วไปที่ผู้ผลิตเกตเวย์สามารถประดิษฐ์ขึ้นโดยอิสระจากเซิร์ฟเวอร์

HTTP POST: ดีที่สุดเมื่อลูกค้าเป็นเจ้าของ Web Endpoint

HTTP มักเป็นตัวเลือกที่ง่ายที่สุดเมื่อลูกค้ามีแอปพลิเคชันเซิร์ฟเวอร์ที่สามารถรับคำขอ POST ได้ เกตเวย์สามารถกำหนดค่าเป็นไคลเอนต์ HTTP และส่ง JSON ไปยัง URL เป้าหมายเป็นระยะ ซึ่งเหมาะกับแบ็กเอนด์เว็บที่กำหนดเองและสภาพแวดล้อมที่ทีมซอฟต์แวร์ต้องการการจัดการคำขอ/การตอบกลับโดยตรง แทนที่จะดำเนินการกับนายหน้า MQTT

เพย์โหลดทั่วไปสามารถมีการประทับเวลา รหัสสถานี และวัตถุพารามิเตอร์ที่มีค่าเซ็นเซอร์ ชื่อฟิลด์ที่แน่นอนเป็นแบบแผนของโครงการ ขั้นตอนสำคัญคือการตกลงเกี่ยวกับประเภทข้อมูล หน่วย พฤติกรรมข้อมูลที่ขาดหายไป และการตอบสนองของเซิร์ฟเวอร์ก่อนปรับใช้

Modbus TCP: ดีที่สุดเมื่อ SCADA หรือ PLC ควรสำรวจข้อมูล

Modbus TCP มีโมเดลการลงทะเบียน Modbus ที่คุ้นเคยผ่านอีเทอร์เน็ต มักจะเหมาะสมเมื่อระบบ PLC, HMI หรือ SCADA ได้รับการออกแบบให้เป็นต้นแบบ Modbus อยู่แล้ว เกตเวย์สามารถเชื่อมโยงอุปกรณ์ RS485 Modbus RTU ไปยังฝั่งอีเธอร์เน็ต หรือเปิดเผยค่าที่รวบรวมผ่านแผนผังการลงทะเบียนที่กำหนดไว้

หากลูกค้าพูดว่า “ให้ที่อยู่ IP แก่เราและแจ้งให้เราทราบว่าแต่ละสัญญาณถูกเก็บไว้ที่ไหน ระบบของเราจะอ่านมัน” โดยปกติแล้ว Modbus TCP จะอยู่ใกล้กับสถาปัตยกรรมที่ต้องการมากกว่า MQTT หรือ HTTP

OPC UA: ดีที่สุดสำหรับการบูรณาการทางอุตสาหกรรมที่สมบูรณ์ยิ่งขึ้น

OPC UA ถูกนำมาใช้กันอย่างแพร่หลายในซอฟต์แวร์อุตสาหกรรม เนื่องจากสามารถนำเสนอข้อมูลเป็นแท็กที่มีชื่อหรือโหนดที่มีโครงสร้างและข้อมูลเมตา แทนที่จะเป็นที่อยู่การลงทะเบียนที่เป็นตัวเลขเท่านั้น เหมาะอย่างยิ่งสำหรับ SCADA มิดเดิลแวร์อุตสาหกรรม และแอปพลิเคชันพีซีที่ต้องการการค้นพบที่เป็นมาตรฐานและลักษณะการสมัครสมาชิก

ไม่ใช่ทุกเกตเวย์ที่รองรับ OPC UA ในบทบาทเดียวกัน ดังนั้นโปรดตรวจสอบว่าเกตเวย์ทำหน้าที่เป็นเซิร์ฟเวอร์ OPC UA ไคลเอนต์ หรือทั้งสองอย่าง ในโปรเจ็กต์ NiuBoL Edge Gateway ที่มีความสามารถมากกว่าเป็นที่ต้องการมากกว่าเมื่อ OPC UA เป็นข้อกำหนดหลัก

คุณควรเลือกโปรโตคอลใด?

ไม่ผสมโปรโตคอลฟิลด์และโปรโตคอลอัปสตรีม

ระบบสามารถใช้ RS485 Modbus RTU จากเซ็นเซอร์ไปยังเกตเวย์ และ MQTT จากเกตเวย์ไปยังคลาวด์ได้ในเวลาเดียวกัน นอกจากนี้ยังสามารถใช้เซ็นเซอร์ 4–20mA ในเกตเวย์ ADC แล้วเปิดเผยค่าเหล่านั้นผ่าน Modbus TCP หรือ OPC UA อินเทอร์เฟซภาคสนามและโปรโตคอลแอปพลิเคชันเป็นเลเยอร์การออกแบบที่แยกจากกัน

การแก้ไขปัญหา: เชื่อมต่อ MQTT แล้ว แต่ไม่มีข้อมูล

1. ยืนยันว่าเลเยอร์เซ็นเซอร์กำลังสร้างข้อมูลภายในเกตเวย์จริงๆ
2. ตรวจสอบช่วงเวลาการอัปโหลดและยืนยันว่าเกตเวย์กำลังเผยแพร่ ไม่ใช่แค่เชื่อมต่อเท่านั้น
3. ตรวจสอบหัวข้อการเผยแพร่ทุกประการ รวมถึงเครื่องหมายสแลชนำหน้าและการพิจารณาตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ซึ่งนายหน้า/แพลตฟอร์มปฏิบัติต่อหัวข้อเหล่านั้นแตกต่างออกไป
4. ใช้ไคลเอ็นต์ MQTT อิสระเพื่อสมัครรับหัวข้อเดียวกัน และแยกเกตเวย์ออกจากแพลตฟอร์มธุรกิจ
5. ตรวจสอบการรับรองความถูกต้อง การขัดแย้งกันของรหัสไคลเอ็นต์ และดูว่าไคลเอ็นต์อื่นใช้ข้อมูลประจำตัวเดียวกันหรือไม่
6. สำหรับ TLS ให้ตรวจสอบความเข้ากันได้ของใบรับรอง CA/เซิร์ฟเวอร์และไลบรารีเฟิร์มแวร์
7. ใช้บันทึกเกตเวย์และการจับเครือข่าย หากจำเป็น เพื่อพิจารณาว่าแพ็กเก็ตออกจากอุปกรณ์หรือไม่ และเซิร์ฟเวอร์ตอบสนองอย่างไร

การแก้ไขปัญหา: เซิร์ฟเวอร์ HTTP ไม่ได้รับอะไรเลย

ขั้นแรกแยกการซื้อจากการอัปโหลด หากบันทึกเกตเวย์แจ้งว่าอุปกรณ์ด้านล่างไม่ตอบสนอง ให้แก้ไขเลเยอร์การสื่อสารของเซ็นเซอร์ก่อนที่จะดีบักเซิร์ฟเวอร์ จากนั้นตรวจสอบ URL เป้าหมาย, พอร์ต, ความสามารถในการเข้าถึง DNS/เครือข่าย, ประเภทเนื้อหา, รูปแบบ JSON และข้อกำหนด HTTPS ฟังก์ชัน HTTP ของเกตเวย์ในสถาปัตยกรรมนี้คือไคลเอนต์ที่ทำการ POST ข้อมูลอย่างแข็งขัน ไม่ใช่เซิร์ฟเวอร์ HTTP โดยอัตโนมัติเพื่อให้ลูกค้าเรียกดู

คำถามที่พบบ่อย

Q1: MQTT ดีกว่า HTTP สำหรับ IoT หรือไม่

A1. ไม่มีดีกว่าในระดับสากล MQTT มีความแข็งแกร่งในด้านกลุ่มยานพาหนะเผยแพร่/สมัครสมาชิก HTTP จะตรงไปตรงมาเมื่อลูกค้ามีจุดรับข้อมูลเว็บอยู่แล้ว

Q2: MQTT “ออนไลน์” หมายความว่าแพลตฟอร์มได้รับข้อมูลเซ็นเซอร์หรือไม่

A2. ไม่ สถานะออนไลน์เป็นเพียงการยืนยันการเชื่อมต่อเท่านั้น หัวข้อ การเผยแพร่ การสมัครสมาชิก และการได้มาซึ่งเซ็นเซอร์ยังต้องได้รับการตรวจสอบ

Q3: อะไรคือความแตกต่างระหว่างหัวข้อเผยแพร่และติดตาม MQTT

A3. เผยแพร่เป็นที่ที่เกตเวย์ส่งการวัดและส่งข้อมูลทางไกล สมัครสมาชิกเป็นที่ที่เกตเวย์ฟังข้อความหรือคำสั่งแบบเซิร์ฟเวอร์ต่ออุปกรณ์

Q4: เกตเวย์ IoT สามารถส่ง JSON โดย HTTP POST ได้หรือไม่

A4. ใช่ บนเกตเวย์/เฟิร์มแวร์ที่รองรับการอัพโหลดไคลเอ็นต์ HTTP เห็นด้วยกับโครงสร้าง JSON และการจัดการการตอบสนองกับทีมเซิร์ฟเวอร์

Q5: พอร์ต 8883 รองรับ MQTTS เสมอหรือไม่

A5. 8883 เป็นเรื่องปกติ แต่เฟิร์มแวร์เกตเวย์และโหมดใบรับรอง TLS จะต้องเข้ากันได้กับนายหน้าเป้าหมาย บันทึกช่วงที่ตกลงไว้ การตอบสนองต่อสัญญาณเตือน การตรวจสอบอินเทอร์เฟซ และหลักฐานการบำรุงรักษาไว้ในเอกสารทดสอบเดินระบบหรือเอกสารตรวจรับ

Q6: เมื่อใดที่ฉันควรใช้ Modbus TCP แทน MQTT

A6. ใช้ Modbus TCP เมื่อต้นแบบทางอุตสาหกรรม เช่น PLC หรือ SCADA ควรสำรวจการลงทะเบียนผ่านอีเทอร์เน็ตอย่างจริงจัง บันทึกช่วงที่ตกลงไว้ การตอบสนองต่อสัญญาณเตือน การตรวจสอบอินเทอร์เฟซ และหลักฐานการบำรุงรักษาไว้ในเอกสารทดสอบเดินระบบหรือเอกสารตรวจรับ

Q7: OPC UA ดีกว่าเมื่อใด

A7. ใช้ OPC UA เมื่อซอฟต์แวร์อุตสาหกรรมได้รับประโยชน์จากแท็ก/โหนดที่ได้มาตรฐาน ข้อมูลเมตา และความสามารถในการทำงานร่วมกันที่สมบูรณ์ยิ่งขึ้น

Q8: หนึ่งเกตเวย์สามารถใช้โปรโตคอลอัพสตรีมมากกว่าหนึ่งโปรโตคอลได้หรือไม่

A8. Edge Gateway จำนวนมากสามารถทำได้ แต่ควรตรวจสอบลักษณะการทำงานของหลายปลายทางพร้อมกันสำหรับเฟิร์มแวร์และโปรเจ็กต์ที่แน่นอน

สรุป