SCADA Archives - Page 2 of 6 - บริษัท ฮันนี่คอร์ปอเรชั่น จำกัด

Aug122026 by contentNo Comments

ISA-88 Batch Process Control: มาตรฐานที่แยก Recipe ออกจาก Equipment Control — เปลี่ยนสูตรโดยไม่ต้องเขียน PLC ใหม่

Article

ลองนึกภาพโรงงานเภสัชกรรมที่ผลิตยา 50 ชนิด แต่ละชนิดต้องใช้สูตร ขั้นตอน และเงื่อนไขการผลิตที่แตกต่างกัน ถ้าวิศวกรต้องเขียนโปรแกรม PLC แยกสำหรับยาแต่ละชนิด สิ่งที่ตามมาคือโค้ดที่ยากต่อการดูแล ซ้ำซ้อน และเปลี่ยนแปลงยาก — นี่คือปัญหาที่มาตรฐาน ISA-88 (Batch Process Control) เข้ามาแก้ ISA-88 หรือ ANSI/ISA-88 เป็นมาตรฐานสากลที่พัฒนาโดย International Society of Automation สำหรับการควบคุมกระบวนการผลิตแบบ Batch Process — กระบวนการที่ผลิตเป็น "ล็อต" (lot/batch) แทนที่จะผลิตต่อเนื่อง โดยแบ่งการผลิตออกเป็นขั้นตอนที่มีต้นตำรับและตำรับยาเฉพาะ ปรัชญาแกนกลาง: แยก "อะไร" ออกจาก "อย่างไร" หัวใจของ ISA-88 คือการแยกสิ่งที่กระบวนการต้องทำ (Recipe) ออกจากวิธีที่อุปกรณ์ทำงานจริง (Equipment Control) แนวคิดนี้ทำให้: การเปลี่ยนสูตรผลิตภัณฑ์ใหม่ไม่ต้องแก้โค้ด PLC แต่เพียงแก้ Recipe ใน Recipe Editor อุปกรณ์เดียวกันสามารถผลิตหลายผลิตภัณฑ์ได้โดยใช้ Recipe ที่แตกต่างกัน Recipe เดียวกันสามารถใช้กับอุปกรณ์คนละชนิดได้ โดยไม่ต้องเขียนโค้ดใหม่ เปรียบเทียบ: โรงงาน Batch เหมือนห้องครัวอาหาร — Physical Model คือห้องครัว (เตาอบ เตาแม่เหล็ก เครื่องผสม) Procedural Model คือเทคนิคการทำอาหารทั่วไป (อุ่นเตา ผสม อบ พัก) ส่วน Recipe คือเมนูเฉพาะของวันนี้ ที่ใช้ห้องครัวและเทคนิคเดียวกัน แต่ผลลัพธ์ต่างกัน โมเดลทั้ง 3 ของ ISA-88 โรงงานผลิตเคมีและเภสัชกรรมที่ใช้ Batch Process — ISA-88 ช่วยจัดการความซับซ้อนของสูตรและขั้นตอนผลิตที่หลากหลาย (Source: Unsplash) 1. Physical Model (โมเดลอุปกรณ์) อธิบายลำดับชั้นของอุปกรณ์ทางกายภาพในโรงงาน จากสูงไปต่ำ: ระดับ คำอธิบาย ตัวอย่าง Enterprise ชั้นธุรกิจ บริษัทแม่ Site โรงงานเฉพาะที่ โรงงานระยอง Area พื้นที่ผลิต เขตผลิตยาเม็ด Process Cell กลุ่ม Unit ที่ทำ Batch ร่วมกัน สายผลิต Batch A Unit เครื่องปฏิกรณ์หรือภาชนะหลัก Reactor R-101 Equipment…

Aug122026 by contentNo Comments

High-Performance HMI: Case Study การออกแบบหน้าจอควบคุมที่ลด Alarm Flood 73% และเร่งการตอบสนอง 66%

Article

"หน้าจอเบลอ สีสันสดใสเกินไป ปุ่มเยอะจนไม่รู้จะกดอะไรก่อน" — นี่คือเสียงบ่นของ Operator หน้าเครื่องจักรมาทุกยุคทุกสมัย เมื่อ HMI (Human Machine Interface) หรือ "ส่วนติดต่อระหว่างมนุษย์และเครื่องจักร" ถูกออกแบบมาแบบผิดวิธี ผลลัพธ์ไม่ใช่แค่ความน่ารำคาญ แต่คืออุบัติเหตุในโรงงานที่อาจสูญเสียทั้งชีวิตและทรัพย์สิน บทความนี้นำเสนอ Case Study การออกแบบ HMI ใหม่ให้โรงงานผลิตเคมีแห่งหนึ่ง ที่เปลี่ยนจากหน้าจอรกๆ ที่มีอุบัติเหตุหลายครั้ง ไปสู่ High-Performance HMI ที่ลด Alarm Flood ได้ 73% และลดเวลาตอบสนองต่อเหตุฉุกเฉินลงกว่าครึ่ง ปัญหา: เมื่อ HMI กลายเป็นส่วนหนึ่งของอุบัติเหตุ โรงงานผลิตเคมีขนาดกลางแห่งนี้มี Operator 12 คน ดูแลสายการผลิต 3 สายด้วย HMI แบบเดิมที่ใช้มา 8 ปี ปัญหาที่พบบ่อยได้แก่: Alarm Flood — บางวันมีการแจ้งเตือนถึง 2,400 ครั้งต่อกะ ทำให้ Operator เพิกเฉยต่อ alarm จริง Color Overload — หน้าจอใช้สีแดง เหลือง เขียว ฟ้า ม่วง พร้อมกัน ทำให้ไม่สามารถแยกได้ว่าสีไหนคือสถานการณ์วิกฤต Navigation Complexity — ต้องคลิกผ่าน 4-5 หน้าจอเพื่อดูข้อมูลที่เกี่ยวข้องกับเครื่องจักรเดียว Average Response Time — Operator ใช้เวลาเฉลี่ย 3.5 นาทีตั้งแต่เกิด alarm จนถึงการตัดสินใจแก้ไข ตัวอย่างหน้าจอ Dashboard ที่แสดงข้อมูลแบบ Real-time — High-Performance HMI ที่ดีต้องมีเพียงข้อมูลที่จำเป็น ไม่ใช่ทุกตัวเลขที่วัดได้ (Source: Unsplash) วิธีแก้: High-Performance HMI Design ทีมวิศวกรได้ปรับปรุงระบบตามหลักการ High-Performance HMI ซึ่งเป็นแนวทางการออกแบบที่เน้นการนำเสนอเฉพาะข้อมูลที่จำเป็น โดยมีหลักการดังนี้: 1. ระบบสีแบบ Gray-Scheme เปลี่ยนพื้นหลังจากสีฟ้าสดเป็น สีเทาอ่อน (Gray-Scheme) และใช้สีเพียง 3 ระดับเพื่อสื่อสารความรุนแรง: สี ความหมาย การตอบสนอง เทา (Gray) สถานะปกติ ทุกอย่างทำงานได้ ไม่ต้องดำเนินการ เหลือง (Yellow) คาดการณ์ปัญหา ค่าเกินขอบเขตปกติ ตรวจสอบภายใน 15…

Aug122026 by contentNo Comments

PLC (Programmable Logic Controller): สมองกลของระบบอัตโนมัติที่วิ่ง Scan Cycle ทุก 1 มิลลิวินาที — วิเคราะห์สถาปัตยกรรมและภาษา IEC 61131-3

Article

ในโรงงานอุตสาหกรรมแทบทุกแห่ง มีอุปกรณ์อิเล็กทรอนิกส์ตัวหนึ่งที่ทำงานเงียบๆ ภายในตู้ควบคุม 24 ชั่วโมงต่อวัน 365 วันต่อปี โดยไม่มีวันหยุด — PLC (Programmable Logic Controller) หรือ "คอนโทรลเลอร์เชิงตรรกะที่โปรแกรมได้" อุปกรณ์นี้คือสมองกลของระบบอัตโนมัติที่คอยรับข้อมูลจากเซ็นเซอร์ ประมวลผลตามโปรแกรมที่วิศวกรเขียนไว้ แล้วสั่งงานอุปกรณ์ประกอบการ (actuator) เช่น วาล์ว มอเตอร์ และคอนเทคเตอร์ ให้ทำงานตามลำดับที่กำหนด บทความนี้เจาะลึกการทำงานของ PLC ตั้งแต่สถาปัตยกรรมฮาร์ดแวร์ กระบวนการ Scan Cycle ภาษาโปรแกรมตามมาตรฐาน IEC 61131-3 ไปจนถึงเทรนด์ล่าสุดในปี 2026 ที่ PLC กำลังกลายเป็น Edge Computing Node ที่เชื่อมโยงกับระบบ Cloud และ AI ได้อย่างไร ประวัติศาสตร์: จาก Relay Logic สู่ Microprocessor ก่อนที่ PLC จะถูกประดิษฐ์ขึ้น in ปี 1968 ระบบควบคุมอัตโนมัติทั้งหมดพึ่งพา Relay Logic — วงจรที่ใช้รีเลย์ไฟฟ้าหลายร้อยตัวเดินสายต่อกันบนแผงวงจรขนาดใหญ่ เมื่อต้องการเปลี่ยนลำดับการทำงาน วิศวกรต้องเดินสายไฟใหม่ทั้งหมด ใช้เวลาหลายวันถึงหลายสัปดาห์ Dick Morley วิศวกรชาวอเมริกัน ได้พัฒนา PLC ตัวแรกชื่อ Modicon 084 สำหรับ General Motors เพื่อแก้ปัญหานี้ ความก้าวล้ำคือการแยก "ฮาร์ดแวร์" ออกจาก "โลจิก" — เปลี่ยนการเดินสายใหม่เป็นการแก้โค้ดซอฟต์แวร์ จากจุดนั้น PLC ก็กลายเป็นหัวใจของระบบอัตโนมัติในโรงงานทั่วโลก ตู้ควบคุมอุตสาหกรรม (Control Cabinet) ที่บรรจุ PLC CPU, โมดูล I/O และอุปกรณ์ควบคุม — บางครั้งประกอบด้วยระบบ Redundancy เพื่อความน่าเชื่อถือสูงสุด สถาปัตยกรรมภายในของ PLC PLC ประกอบด้วยส่วนหลัก 4 ส่วนที่ทำงานประสานกัน: ส่วนประกอบ หน้าที่ คุณสมบัติเด่น CPU / Processor ประมวลผลโปรแกรมควบคุม คำนวณโลจิก และจัดการการสื่อสาร ความเร็วระดับไมโครวินาที, บางรุ่นรองรับ 64-bit dual-core Input Modules รับสัญญาณจากเซ็นเซอร์ (ดิจิทัล 24VDC หรืออะนาล็อก 4-20mA) Optical isolation ป้องกันกระแสไฟเกิน, รองรับ…

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 กรณีใช้งานในโรงงาน…

Aug22026 by contentNo Comments

Digital Thread: สายดิจิทัลที่เชื่อมข้อมูลผลิตภัณฑ์ตลอดวงจรชีวิต จากแบบร่างสู่การส่งมอบ

Article

หาก Digital Twin คือ "ภาพสะท้อน" ของสินทรัพย์หรือกระบวนการในเวลาหนึ่ง Digital Thread ก็คือ "เส้นเวลา" ที่เชื่อมข้อมูลของผลิตภัณฑ์ตั้งแต่ต้นน้ำจนถึงปลายน้ำ — ตั้งแต่การออกแบบใน CAD, การวางแผนการผลิตใน ERP, การควบคุมสายการผลิตใน SCADA ไปจนถึงการบำรุงรักษาและการรีไซเคิล เส้นดิจิทัลนี้คือกระดูกสันหลังของอุตสาหกรรม 4.0 ที่ผู้ผลิตชั้นนำทั่วโลกกำลังลงทุนสร้างขึ้นอย่างจริงจัง ภาพประกอบ: การพัฒนาผลิตภัณฑ์ในยุคดิจิทัลต้องเชื่อมโยงข้อมูลระหว่างทีมออกแบบ วิศวกรรม และการผลิต (ที่มา: Unsplash) Digital Thread คืออะไร? และทำไมจึงสำคัญกว่าที่คิด Digital Thread คือกระแสข้อมูลที่ไหลผ่านระบบต่างๆ อย่างต่อเนื่องตลอดวงจรชีวิตของผลิตภัณฑ์ (Product Lifecycle) โดยรักษาความสัมพันธ์และการสืบย้อนกลับ (Traceability) ของข้อมูลไว้ได้ แนวคิดนี้มีรากฐานจาก Model-Based Systems Engineering (MBSE) ซึ่งมองว่าผลิตภัณฑ์ทุกชิ้นควรมี "โมเดลแม่" (Authoritative Source) ที่ทุกระบบอ้างอิงกลับไป ความแตกต่างสำคัญระหว่าง Digital Twin และ Digital Thread คือ มิติของเวลา Digital Twin สะท้อนสถานะปัจจุบันของสินทรัพย์หนึ่งในขณะนี้ ส่วน Digital Thread เก็บประวัติและความสัมพันธ์ของข้อมูลทั้งหมดตั้งแต่กำเนิดจนสิ้นสุดอายุการใช้งาน กล่าวอีกนัยหนึ่ง Digital Twin คือภาพถ่าย ส่วน Digital Thread คือภาพยนตร์ที่บันทึกเรื่องราวทั้งหมด จุดเชื่อม 5 ด่านของวงจรผลิตภัณฑ์ Digital Thread เชื่อมระบบข้อมูล 5 ด่านหลักที่ในอดีตทำงานแยกขาดจากกัน ทำให้เกิด "เกาะข้อมูล" (Data Silo) ที่ทำให้ไม่สามารถสืบย้อนได้ว่าการตัดสินใจในด่านหนึ่งส่งผลต่ออีกด่านอย่างไร: ด่าน (Phase) ระบบหลัก ประเภทข้อมูล 1. As-Designed (ออกแบบ) PLM / CAD / CAE โมเดล 3 มิติ, BOM (Bill of Materials), สเปกวัสดุ 2. As-Planned (วางแผน) ERP / APS แผนการผลิต, ใบสั่งผลิต, การจัดซื้อวัตถุดิบ 3. As-Built (ผลิตจริง) MES / SCADA พารามิเตอร์เครื่องจักร, หมายเลขชุดผลิต, ผล QC 4. As-Maintained (ดูแลรักษา) CMMS…

Jul292026 by contentNo Comments

ISA-18.2 Alarm Management: มาตรฐานลด Alarm Flood ที่ช่วยชีวิตวิศวกรในห้องควบคุม

Article

เมื่อวันที่ 23 มีนาคม 2005 เหตุระเบิดที่โรงกลั่น Texas City ของ BP คร่าชีวิตคนงาน 15 ราย บาดเจ็บ 180 ราย รายงานสืบสวนของ CSB (U.S. Chemical Safety Board) ชี้ชัดถึงสาเหตุหนึ่ง: Alarm Flood โอเปอเรเตอร์เผชิญ Alarm กว่า 275 ครั้งใน 17 นาที จนไม่สามารถแยกแยะ Alarm สำคัญจาก Noise ได้ เหตุการณ์นี้กลายเป็นจุดเปลี่ยนที่ทำให้ ISA-18.2 Alarm Management Standard กลายเป็นมาตรฐานสากลที่โรงงาน Process Industry ทั่วโลกยอมรับ ISA-18.2 คืออะไร? ISA-18.2 (ANSI/ISA-18.2) คือมาตรฐาน "Management of Alarm Systems for the Process Industries" ที่เผยแพร่ครั้งแรกในปี 2009 และอัปเดตเป็น ISA-18.2-2016 โดยกำหนด Workflow ครบวงจรตั้งแต่การออกแบบ ติดตั้ง ดำเนินการ ตรวจสอบ ไปจนถึงการ Retire Alarm ที่ไม่จำเป็น เป้าหมายคือสร้างระบบ Alarm ที่ ตรงประเด็น ลำดับความสำคัญชัดเจน แม่นยำ และทันเวลา แนวคิดหลักของ ISA-18.2 คือการมอง Alarm เป็น Lifecycle ไม่ใช่ "ตั้งครั้งเดียวจบ" เพราะสภาพโรงงานเปลี่ยนไปตลอดเวลา ทำให้ Alarm ที่เคยถูกต้องอาจกลายเป็น Nuisance Alarm ในอนาคต Alarm Management Lifecycle 7 ขั้นตอน Philosophy: กำหนดนโยบาย เกณฑ์การแจ้งเตือน, Priority Scheme, Performance Target Identification: ระบุ Alarm ที่จำเป็นจาก Hazard Analysis (HAZOP, LOPA) Rationalization: ทบทวน Alarm ทีละตัว กำหนด Priority (Critical/High/Medium/Low), Setpoint, Deadband Detailed Design: ออกแบบ HMI Presentation, Color Coding,…

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 ส่ง →…

Jul272026 by contentNo Comments

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

Article

MQTT (Message Queuing Telemetry Transport) เป็นโปรโตคอลสื่อสารแบบ lightweight ที่ออกแบบมาเพื่อส่งข้อมูลจากอุปกรณ์ที่มีทรัพยากรจำกัด เช่น เซ็นเซอร์อุณหภูมิ มอเตอร์ หรือ PLC ในโรงงานอุตสาหกรรม โดยใช้สถาปัตยกรรม Publish/Subscribe ที่แยกผู้ส่งและผู้รับออกจากกัน ทำให้ระบบสามารถขยายตัวได้ถึง หลายล้านการเชื่อมต่อพร้อมกัน โดยไม่ต้องเปลี่ยนแปลงโครงสร้าง สถาปัตยกรรม Publish/Subscribe ทำงานอย่างไร? ใน MQTT จะมี Broker ทำหน้าที่เป็นศูนย์กลางกระจายข้อความ อุปกรณ์ที่ต้องการส่งข้อมูล (Publisher) จะส่งข้อความไปยังหัวข้อที่เรียกว่า Topic เช่น factory/line1/temp_sensor_01 ส่วนอุปกรณ์ที่ต้องการรับข้อมูล (Subscriber) จะสมัครรับข้อมูลจาก Topic ที่สนใจ ข้อดีคือ Publisher ไม่จำเป็นต้องรู้ว่าใครจะรับข้อมูล ทำให้การเพิ่ม-ลดอุปกรณ์ไม่กระทบกัน ข้อได้เปรียบหลัก: Publisher และ Subscriber ทำงานแบบ Decoupled ทั้งเชิงพื้นที่ เชิงเวลา และเชิงการซิงโครไนซ์ → ระบบสื่อสารยืดหยุ่นสูง ขยายได้ง่าย ทนต่อการขาดหายของอุปกรณ์บางตัว QoS (Quality of Service) — ระดับคุณภาพการส่งข้อมูล MQTT กำหนดระดับ QoS ไว้ 3 ระดับ เพื่อให้ผู้พัฒนาเลือกสมดุลระหว่างความเชื่อถือได้และประสิทธิภาพ ระดับ QoS ชื่อ การรับประกัน การแลกเปลี่ยนข้อความ 0 At most once ส่งครั้งเดียว ไม่รับประกันถึง (Fire and Forget) 1 ครั้ง (PUBLISH) 1 At least once รับประกันว่าข้อความจะถึงอย่างน้อย 1 ครั้ง (อาจซ้ำ) 2 ครั้ง (PUBLISH + PUBACK) 2 Exactly once รับประกันว่าข้อความจะถึงพอดี 1 ครั้ง ไม่ซ้ำ 4 ครั้ง (PUBLISH + PUBREC + PUBREL + PUBCOMP) ในโรงงานจริง การเลือก QoS ขึ้นอยู่กับชนิดข้อมูล: ข้อมูลอุณหภูมิที่ส่งทุก 5 วินาทีใช้ QoS 0 ได้ (หากหายไปครั้งเดียวไม่วิกฤต) แต่คำสั่งควบคุมเช่น "หยุดมอเตอร์" ต้องใช้ QoS…

Jul262026 by contentNo Comments

ERP-MES-SCADA Integration ตามมาตรฐาน ISA-95: สถาปัตยกรรมการเชื่อมต่อ 3 ระบบที่ขับเคลื่อน Smart Factory

Article

ทำไม ERP, MES และ SCADA ต้องเชื่อมกัน? ทำความเข้าใจ ISA-95 Integration ในโรงงานอุตสาหกรรมขนาดใหญ่ มักมีระบบสารสนเทศทำงานอยู่อย่างน้อย 3 ระดับ: ERP (Enterprise Resource Planning) ที่ระดับองค์กร, MES (Manufacturing Execution System) ที่ระดับโรงงาน และ SCADA/PLC ที่ระดับเครื่องจักร ปัญหาที่พบบ่อยที่สุดคือระบบทั้งสามทำงานแบบ "เกาะแยก" (Silo) ข้อมูลไม่ไหลข้ามระบบ ส่งผลให้การตัดสินใจล่าช้าและไม่แม่นยำ มาตรฐาน ISA-95 (ฉบับย่อคือ ANSI/ISA-95) คือกรอบงานสากลที่นิยามวิธีเชื่อมต่อระบบทั้งสามระดับนี้เข้าด้วยกันอย่างเป็นระบบ โดยแบ่งโลกของการผลิตออกเป็น 5 ระดับ (Level 0 ถึง Level 4) และกำหนด Interface มาตรฐานสำหรับการแลกเปลี่ยนข้อมูลระหว่างระดับ สถาปัตยกรรม ISA-95: 5 ระดับของพีรามิดการผลิต Level ระบบ ขอบเขตเวลา หน้าที่หลัก Level 4 ERP วัน – เดือน – ปี วางแผนธุรกิจ สั่งซื้อ การเงิน Level 3 MES ชั่วโมง – กะ – วัน จัดตารางผลิต ติดตาม OEE Level 2 SCADA / HMI วินาที – นาที ควบคุม ติดตามกระบวนการ Level 1 PLC / DCS มิลลิวินาที ควบคุมเครื่องจักรแบบ Loop Level 0 Field Devices ไมโครวินาที เซ็นเซอร์ แอคชูเอเตอร์ 💡 หลักการสำคัญ: แต่ละ Level ทำงานในกรอบเวลา (Time Horizon) ที่ต่างกัน ERP วางแผนเป็นเดือน PLC ตอบสนองในมิลลิวินาที การเชื่อมต่อที่ดีต้อง "แปล" ข้อมูลให้เหมาะกับกรอบเวลาของแต่ละระดับ ไม่ใช่ส่งข้อมูลดิบข้ามทุกระดับ ข้อมูลไหลอย่างไรระหว่าง 3 ระบบ? จาก ERP ลงสู่ MES (Top-Down) เมื่อ ERP สร้าง Production…