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

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

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

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

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

แม้ 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 และ HTTP/HTTPS ที่สำคัญ OPC UA ไม่ขึ้นกับแพลตฟอร์ม จึงสามารถผสานรวมได้โดยตรงภายในเอดจ์เกตเวย์บน Linux คอนโทรลเลอร์แบบฝังตัว และสภาพแวดล้อมคลาวด์

นอกจากนี้ OPC UA ยังนำเสนอโมเดลข้อมูลสารสนเทศแบบออบเจ็กต์ออเรียนเต็ด แทนที่จะส่งค่าทศนิยมลอยตัวแบบแยกเดี่ยว 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 ของ The Open Group โดย O-PAS มีเป้าหมายเพื่อสร้างสถาปัตยกรรมแบบเปิดที่ไม่ขึ้นกับฮาร์ดแวร์สำหรับระบบอัตโนมัติกระบวนการ ซึ่งกำหนดขึ้นบนเสาหลัก 3 ประการ:

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

รูปที่ 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 ทำหน้าที่เป็นชั้นนามธรรมของซอฟต์แวร์แบบรวมศูนย์และเรียลไทม์ ซึ่งเป็น "แหล่งข้อมูลจริงเพียงแหล่งเดียว" สำหรับข้อมูลการปฏิบัติงานและข้อมูลธุรกิจทั้งหมดภายในองค์กร

รูปที่ 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 องค์กรอุตสาหกรรมจึงสามารถเพิ่ม แก้ไข หรือขยายเครื่องมือซอฟต์แวร์และเซ็นเซอร์เอดจ์ได้โดยไม่ต้องออกแบบลูปควบคุมที่มีอยู่ใหม่

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

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

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

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

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

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

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