กลับไปยังบล็อก

วิวัฒนาการของโปรโตคอลการสื่อสารในภาคอุตสาหกรรม: จาก Modbus สู่ UNS และ O-PAS

บทวิเคราะห์เชิงลึกที่ติดตามการเปลี่ยนแปลงของเครือข่ายอุตสาหกรรมจากบัสแบบกรรมสิทธิ์เฉพาะรุ่นดั้งเดิมไปสู่มาตรฐานเปิด เช่น OPC UA, MQTT และ Unified Namespace (UNS) สำรวจสถาปัตยกรรมทางเทคนิค การผสานรว...

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

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

รากฐานของเครือข่ายในโรงงาน: Modbus, PLC ยุคแรก และการแตกแขนงของโปรโตคอล

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

ในปี 1979 Modicon (ปัจจุบันคือ Schneider Electric) ได้เปิดตัวมาตรฐาน Modbus ซึ่งเปลี่ยนโฉมการสื่อสารในภาคอุตสาหกรรมโดยพื้นฐาน Modbus ออกแบบบนสถาปัตยกรรมแม่ข่าย/ลูกข่าย (ปัจจุบันเรียกว่าไคลเอนต์/เซิร์ฟเวอร์) ที่ทำงานผ่านอินเทอร์เฟซอนุกรม เช่น RS-485 โดยนำเสนอโปรโตคอลแบบเปิดและปลอดค่าลิขสิทธิ์ ซึ่งทำให้การดึงข้อมูลระดับรีจิสเตอร์ง่ายขึ้น ความเรียบง่ายและการนำไปใช้งานที่สะดวกทำให้โปรโตคอลนี้กลายเป็นมาตรฐานที่แพร่หลาย และยังคงสถานะดังกล่าวในจุดปลายทางที่ใช้งานจริงนับล้านจุดในปัจจุบัน

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

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

  • Siemens นำ PROFIBUS และต่อมา PROFINET มาใช้เพื่อรองรับการแลกเปลี่ยนข้อมูล I/O แบบเป็นรอบด้วยความเร็วสูง รวมถึงแฟล็กการวินิจฉัยที่ซับซ้อนระหว่างสถานีภาคสนามแบบกระจาย เช่น คอนโทรลเลอร์ Siemens SIMATIC
  • Allen-Bradley / Rockwell Automation เปิดตัว Data Highway Plus (DH+) และ ControlNet ซึ่งต่อมาได้พัฒนาเป็น EtherNet/IP ผ่าน Common Industrial Protocol (CIP)
  • Mitsubishi Electric นำ CC-Link มาใช้เพื่อส่งมอบการควบคุมแบบกำหนดเวลาได้อย่างแน่นอนด้วยความเร็วสูง ผ่านชั้นกายภาพเฉพาะที่ทนทานต่อสัญญาณรบกวน

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

ยุติการผูกติดกับผู้จำหน่าย: จาก OPC Classic สู่ OPC UA ที่ไม่ขึ้นกับแพลตฟอร์ม

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

ในปี 1996 กลุ่มผู้จำหน่ายระบบอัตโนมัติได้ร่วมมือกับ Microsoft เพื่อสร้างมาตรฐาน Open Platform Communications (OPC) ซึ่งต่อมาได้รับการกำหนดชื่อเป็น OPC Classic โดยมีพื้นฐานจากเทคโนโลยี OLE, COM และ DCOM ของ Microsoft ทำให้ OPC Classic กำหนดอินเทอร์เฟซไคลเอ็นต์-เซิร์ฟเวอร์ที่เป็นมาตรฐานสำหรับการเข้าถึงข้อมูล (OPC DA), สัญญาณเตือนและเหตุการณ์ (OPC AE) และการเข้าถึงข้อมูลย้อนหลัง (OPC HDA) ผู้จำหน่ายระบบอัตโนมัติเพียงจัดหา OPC Server สำหรับฮาร์ดแวร์ของตน จากนั้นซอฟต์แวร์ HMI หรือ SCADA ที่รองรับ OPC ใด ๆ ก็สามารถอ่านและเขียนข้อมูลได้อย่างราบรื่น

อย่างไรก็ตาม การพึ่งพา Microsoft DCOM ได้สร้างความท้าทายด้านการดำเนินงานโดยเฉพาะ เมื่อเครือข่ายอุตสาหกรรมเริ่มพัฒนาให้ทันสมัย:

  • การพึ่งพาระบบปฏิบัติการ: เซิร์ฟเวอร์ OPC Classic ทำงานได้เฉพาะบนระบบปฏิบัติการ Windows เท่านั้น ทำให้ไม่รองรับคอนโทรลเลอร์ Linux แบบฝังตัว อุปกรณ์ RTOS และเซิร์ฟเวอร์องค์กร Unix
  • ข้อจำกัดด้านความปลอดภัย: การกำหนดค่า DCOM ข้ามไฟร์วอลล์และขอบเขตซับเน็ตเป็นเรื่องที่ยากอย่างมาก จนเป็นที่เลื่องลือว่าซับซ้อนและต้องเปิดช่วงพอร์ตจำนวนมาก ซึ่งก่อให้เกิดช่องโหว่ด้านความปลอดภัยไซเบอร์อย่างร้ายแรง
  • ขาดบริบทเชิงความหมาย: ข้อมูลส่วนใหญ่ถูกส่งเป็นค่าดิบโดยไม่มีบริบท หน่วยทางวิศวกรรม หรือข้อมูลเมตาเชิงความหมายที่ฝังอยู่ในเฟรมการส่งข้อมูลโดยตรง

เพื่อแก้ไขจุดเปราะบางด้านสถาปัตยกรรมเหล่านี้ OPC Foundation ได้เผยแพร่ OPC Unified Architecture (OPC UA) ในปี 2008 โดย OPC UA ยกเลิก DCOM และหันมาใช้สถาปัตยกรรมแบบเปิดที่ขับเคลื่อนด้วยบริการ (SOA) ซึ่งใช้ TCP/IP และชั้นการขนส่ง TCP/IP และ HTTP/HTTPS ที่สำคัญ OPC UA ไม่ขึ้นกับแพลตฟอร์ม จึงสามารถผสานรวมได้โดยตรงกับเกตเวย์เอดจ์บน Linux คอนโทรลเลอร์แบบฝังตัว และสภาพแวดล้อมคลาวด์

นอกจากนี้ OPC UA ยังนำเสนอ Information Model เชิงวัตถุ แทนที่จะส่งค่าจุดลอยตัวที่แยกเดี่ยว OPC UA จะห่อหุ้มข้อมูลเป็นออบเจ็กต์ที่ซับซ้อน ซึ่งประกอบด้วยหน่วยทางวิศวกรรม ขีดจำกัดการแจ้งเตือนสูงสุด/ต่ำสุด ความละเอียดของการประทับเวลา และสิทธิ์การเข้าถึง เมื่อทำงานร่วมกับการเข้ารหัส PKI ในตัวและการยืนยันตัวตนด้วยใบรับรอง x509 แล้ว OPC UA จึงเป็นรากฐานสำคัญของการหลอมรวม IT/OT ที่ปลอดภัย

สถาปัตยกรรม DCS, O-PAS และการควบคุมแบบไฮบริดสมัยใหม่

แม้ PLC จะโดดเด่นด้านการควบคุมแบบไม่ต่อเนื่องความเร็วสูง แต่อุตสาหกรรมกระบวนการ เช่น การกลั่นปิโตรเคมี การผลิตไฟฟ้า และเคมีภัณฑ์เฉพาะทาง ในอดีตพึ่งพาระบบควบคุมแบบกระจาย (DCS) โดย DCS จะผสานคอนโทรลเลอร์ ระบบย่อย I/O ฐานข้อมูลฮิสทอเรียน และเวิร์กสเตชันของผู้ปฏิบัติงานเข้าไว้ในสภาพแวดล้อมทางวิศวกรรมแบบรวมเป็นหนึ่ง

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

ระดับการทำงานของสถาปัตยกรรมระบบควบคุมแบบกระจาย ซึ่งเชื่อมโยงเครื่องมือวัดภาคสนามกับการควบคุมระดับองค์กร

รูปที่ 1 ระดับการทำงานของระบบควบคุมแบบกระจาย (DCS) ที่แสดงชั้นการควบคุมตามลำดับชั้นแบบดั้งเดิม ภาพเอื้อเฟื้อจาก Wikipedia Commons

เพื่อเปลี่ยนแปลงกระบวนทัศน์นี้ ผู้ประกอบการอุตสาหกรรมรายใหญ่ที่นำโดย ExxonMobil ได้ริเริ่มมาตรฐาน Open Process Automation Standard (O-PAS) ภายใต้ OPA Forum ของ The Open Group โดย O-PAS มีเป้าหมายเพื่อสร้างสถาปัตยกรรมแบบเปิดที่ไม่ยึดติดกับฮาร์ดแวร์สำหรับระบบอัตโนมัติในกระบวนการ ซึ่งกำหนดขึ้นบนเสาหลักสำคัญสามประการ:

  1. ความสามารถในการทำงานร่วมกัน: บัสสื่อสารมาตรฐาน (ที่ใช้ OPC UA) ซึ่งช่วยให้ส่วนประกอบจากผู้ผลิตฮาร์ดแวร์ต่างรายแลกเปลี่ยนข้อมูลกันได้โดยตรง โดยไม่ต้องพัฒนาไดรเวอร์แบบกำหนดเอง
  2. ความเป็นโมดูล: การแยกแอปพลิเคชันซอฟต์แวร์ออกจากฮาร์ดแวร์พื้นฐานผ่านไมโครเซอร์วิสแบบคอนเทนเนอร์และโหนดควบคุมแบบกระจาย (DCN)
  3. ความปลอดภัย: การรักษาความปลอดภัยทางไซเบอร์ในตัวที่สอดคล้องกับมาตรฐาน IEC 62443 และบังคับใช้ที่ขอบเขตของอุปกรณ์ทุกจุด

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

เทเลเมทรีที่ขับเคลื่อนด้วยเหตุการณ์: MQTT และเครือข่ายเอดจ์แบนด์วิดท์ต่ำ

เมื่อเครื่องมือวัดภาคสนามพัฒนาจากเซนเซอร์ดิสครีตพื้นฐานไปเป็นทรานสมิตเตอร์อัจฉริยะที่ซับซ้อน ซึ่งสามารถรายงานพารามิเตอร์การวินิจฉัยได้หลายร้อยรายการ ข้อจำกัดด้านการปฏิบัติงานของเครือข่ายไคลเอนต์-เซิร์ฟเวอร์แบบร้องขอ/ตอบกลับดั้งเดิมก็เริ่มปรากฏชัดเจน

ในปี 1999 Andy Stanford-Clark (IBM) และ Arlen Nipper (Arcom ซึ่งปัจจุบันคือ Cirrus Link) ได้พัฒนา Message Queuing Telemetry Transport (MQTT) ขึ้นโดยเฉพาะเพื่อแก้ไขข้อจำกัดด้านแบนด์วิดท์และเวลาแฝงในแอปพลิเคชัน SCADA ระยะไกล เช่น การตรวจสอบท่อส่งน้ำมันและก๊าซผ่านลิงก์ดาวเทียม ในสภาพแวดล้อมเหล่านี้ การโพลอย่างต่อเนื่องผ่านการเชื่อมต่อที่มีเวลาแฝงสูงมีต้นทุนสูงและไม่น่าเชื่อถือ

MQTT แก้ไขความท้าทายเหล่านี้ด้วยสถาปัตยกรรม Publish/Subscribe (Pub/Sub) ที่ขับเคลื่อนด้วยเหตุการณ์และใช้โบรกเกอร์ข้อความส่วนกลาง:

  • การสื่อสารแบบแยกส่วน: โหนดเอดจ์ (ผู้เผยแพร่) และซอฟต์แวร์ระดับองค์กร (ผู้สมัครรับข้อมูล) ไม่ได้สร้างการเชื่อมต่อโดยตรงแบบจุดต่อจุด แต่สื่อสารแบบอะซิงโครนัสผ่าน MQTT Broker
  • โอเวอร์เฮดต่ำ: ด้วยส่วนหัวขนาดกะทัดรัด 2 ไบต์ MQTT จึงลดการใช้แบนด์วิดท์ลงอย่างมากเมื่อเทียบกับ API ของ HTTP/REST หรือโปรโตคอล RPC ที่มีน้ำหนักมาก
  • การรายงานเมื่อมีข้อยกเว้น (RBE): อุปกรณ์ภาคสนามจะเผยแพร่ข้อมูลเฉพาะเมื่อค่ามีการเปลี่ยนแปลงเกินเดดแบนด์หรือเกณฑ์สถานะที่กำหนดไว้ ช่วยลดทราฟฟิกจากการโพลที่ไม่จำเป็นบนเครือข่าย
  • การรับรู้สถานะ: ฟีเจอร์ต่าง ๆ เช่น ตัวจับเวลา "Keep Alive" และ "Last Will and Testament" (LWT) ช่วยให้โบรกเกอร์แจ้งเตือนผู้สมัครรับข้อมูลได้ทันที หากอุปกรณ์เอดจ์ตัดการเชื่อมต่อกะทันหัน

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

รูปที่ 2 โมเดล Publish/Subscribe ในสถาปัตยกรรมเครือข่าย MQTT ที่เชื่อมต่อโหนดเอดจ์กับโบรกเกอร์แอปพลิเคชันส่วนกลาง ภาพจาก Wikipedia Commons

แม้ MQTT แบบธรรมดาจะมีกลไกการขนส่งเพย์โหลดที่ยืดหยุ่น แต่ไม่ได้กำหนดมาตรฐานว่าวิธีจัดรูปแบบโครงสร้างหัวข้อหรือเพย์โหลดควรเป็นอย่างไร เพื่อแก้ปัญหานี้ ชุมชนอุตสาหกรรมจึงพัฒนาข้อกำหนด Sparkplug B ขึ้น Sparkplug B กำหนดเนมสเปซหัวข้อมาตรฐาน โครงสร้างเพย์โหลด Google Protocol Buffer (Protobuf) ขนาดกะทัดรัด และกลไกการจัดการสถานะ ซึ่งเปลี่ยน MQTT ดิบให้เป็นเลเยอร์การขนส่งเชิงอุตสาหกรรมที่พร้อมใช้งานระดับองค์กร

กระบวนทัศน์อุตสาหกรรมสมัยใหม่: สถาปัตยกรรม Unified Namespace (UNS)

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

เพื่อขจัดคอขวดด้านการผสานรวมเหล่านี้ วิศวกรระบบอัตโนมัติยุคใหม่จึงนำสถาปัตยกรรม Unified Namespace (UNS) มาใช้ Unified Namespace ทำหน้าที่เป็นเลเยอร์นามธรรมด้านซอฟต์แวร์แบบรวมศูนย์และเรียลไทม์ ซึ่งเป็น "แหล่งข้อมูลจริงเพียงแหล่งเดียว" สำหรับข้อมูลการปฏิบัติงานและข้อมูลธุรกิจทั้งหมดภายในองค์กร

สถาปัตยกรรม Unified Namespace ที่แสดงโบรกเกอร์ MQTT แบบรวมศูนย์ซึ่งเชื่อมต่อ PLC, SCADA, MES และระบบองค์กร

รูปที่ 3. โครงสร้าง Unified Namespace (UNS) ที่ประสานการไหลของข้อมูลแบบเรียลไทม์ข้ามทุกเลเยอร์องค์กรของ ISA-95 ภาพเอื้อเฟื้อจาก Wikipedia Commons

UNS ซึ่งมีพื้นฐานอยู่บนโมเดลเผยแพร่/สมัครรับ—โดยทั่วไปใช้งานผ่าน MQTT Sparkplug B หรือแพลตฟอร์มสตรีมเหตุการณ์—จะจัดโครงสร้างข้อมูลตามความหมายโดยอิงลำดับชั้นทางกายภาพมาตรฐาน เช่น ISA-95:

องค์กร / ไซต์ / พื้นที่ / สายการผลิต / เซลล์ / สินทรัพย์

ในกรอบงาน UNS ที่ใช้งานได้อย่างสมบูรณ์:

  • PLC ภาคสนามเผยแพร่สถานะมอเตอร์โดยตรงไปยัง Enterprise/Plant_A/Line_2/Mixer/Motor_Speed เมื่อสถานะเปลี่ยนแปลง
  • ระบบ SCADA สมัครรับโครงสร้างหัวข้อเพื่อแสดงกราฟิกสำหรับผู้ปฏิบัติงานแบบเรียลไทม์
  • ระบบจัดการสินทรัพย์องค์กร (EAM) รับฟังสตรีมหัวข้อเดียวกันเพื่อติดตามชั่วโมงการทำงานและจัดกำหนดการบำรุงรักษาเชิงป้องกันโดยอัตโนมัติ
  • โมเดลแมชชีนเลิร์นนิงบนคลาวด์รับข้อมูลจากสตรีมข้อมูลแบบรวมศูนย์เพื่อดำเนินการตรวจจับความผิดปกติเชิงคาดการณ์ โดยไม่เพิ่มภาระการโพลให้กับคอนโทรลเลอร์ภาคสนาม

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

ตารางเมทริกซ์และการเปรียบเทียบทางเทคนิคของโปรโตคอลในแต่ละระดับ

การเลือกกลยุทธ์โปรโตคอลที่เหมาะสมที่สุดจำเป็นต้องทำความเข้าใจคุณลักษณะด้านประสิทธิภาพทางเทคนิค ภาระโอเวอร์เฮดของเพย์โหลด และแอปพลิเคชันเป้าหมายของแต่ละเลเยอร์เครือข่ายทั่วทั้งระบบนิเวศการปฏิบัติงาน:

โปรโตคอล สถาปัตยกรรม ชั้นการขนส่ง เพย์โหลดข้อมูลและบริบท พื้นที่การใช้งานหลัก
Modbus RTU/TCP ไคลเอนต์/เซิร์ฟเวอร์ (การโพลล์) RS-485 / TCP/IP รีจิสเตอร์ดิบ 16 บิต, ไม่มีเมทาดาทา อุปกรณ์รุ่นเก่า, มิเตอร์วัดกำลังไฟฟ้า, เครือข่ายเซนเซอร์พื้นฐาน
PROFINET / EtherNet/IP การสื่อสารแบบผู้ผลิต/ผู้บริโภคเป็นรอบ อีเทอร์เน็ต / ชั้นกายภาพแบบกำหนดเอง เฟรม I/O แบบกำหนดเวลาแน่นอน, การวินิจฉัยระดับอุปกรณ์ การควบคุมแบบดิสครีตความเร็วสูง, การควบคุมการเคลื่อนที่, I/O ภาคสนาม
OPC UA ไคลเอนต์/เซิร์ฟเวอร์ และการเผยแพร่/สมัครรับ TCP/IP, HTTP/HTTPS, WebSockets โมเดลอ็อบเจ็กต์ที่มีรายละเอียดสูง, เมทาดาทา, ใบรับรองการเข้ารหัส PLC ถึง SCADA, การสื่อสารระหว่างคอนโทรลเลอร์, การเชื่อมต่อ IT/OT
MQTT / Sparkplug B การสื่อสารแบบเผยแพร่/สมัครรับผ่านโบรกเกอร์ส่วนกลาง TCP/IP, TLS (น้ำหนักเบา) รายงานเมื่อมีข้อยกเว้น, เพย์โหลด Protobuf พร้อมหัวข้อเชิงความหมาย สถาปัตยกรรม UNS, เซนเซอร์เอดจ์ IIoT, การวิเคราะห์เทเลเมทรีบนคลาวด์

วิศวกรรมสถาปัตยกรรมในโลกจริง: ยกระดับการดำเนินงานของโรงงานรุ่นเก่า

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

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

  1. ระยะที่ 1: เลเยอร์แปลโปรโตคอลที่เอดจ์
    ติดตั้งเอดจ์เกตเวย์อุตสาหกรรมใกล้กับตู้แร็ก PLC รุ่นเก่า เอดจ์เกตเวย์จะอ่านค่าจากรีจิสเตอร์จัดเก็บข้อมูลภายในผ่านอนุกรมหรือโปรโตคอลฟิลด์บัสรุ่นเก่า แล้วแปลงค่าดิบเป็นโหนด OPC UA ที่มีโครงสร้าง หรือหัวข้อ MQTT Sparkplug B
  2. ระยะที่ 2: การติดตั้งโบรกเกอร์และการจัดโครงสร้าง UNS
    ติดตั้ง MQTT Broker แบบความพร้อมใช้งานสูงและมีความซ้ำซ้อนภายในโรงงาน กำหนดเนมสเปซหัวข้อแบบ ISA-95 ที่เป็นหนึ่งเดียวทั่วทั้งพื้นที่การผลิต ส่งข้อมูลเทเลเมทรีจากเอดจ์เกตเวย์เข้าสู่โบรกเกอร์ ซึ่งทำให้มองเห็นสถานะแบบเรียลไทม์ของอุปกรณ์ได้ทันที โดยไม่ต้องเปลี่ยนแปลงเวลาสแกนของ PLC หรือโลจิกควบคุมพื้นฐาน
  3. ระยะที่ 3: การผสานรวมการวิเคราะห์ขั้นสูงและการควบคุมแบบไฮบริด
    เชื่อมต่อระบบจัดเก็บประวัติข้อมูลระดับองค์กร เอนจินวิเคราะห์บนคลาวด์ และระบบ HMI สมัยใหม่เข้ากับ UNS โดยตรงในฐานะผู้สมัครรับข้อมูล เมื่อคอนโทรลเลอร์รุ่นเก่าหมดอายุการใช้งาน ให้เปลี่ยนเป็น PAC สมัยใหม่แบบสถาปัตยกรรมเปิดที่รองรับสภาพแวดล้อม OPC UA และ MQTT โดยกำเนิด

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

แสดงความคิดเห็น

โปรดทราบว่าความคิดเห็นจะต้องได้รับการอนุมัติก่อนที่จะได้รับการเผยแพร่