เก็บข้อมูลจาก PLC ปี 2026 สาเหตุที่เก็บไม่ได้ไม่ใช่มาตรฐานการสื่อสาร แต่คือจำนวนแท็กกับรอบการเก็บ

เวลาได้รับคำถามว่า “เครื่องจักรตัวนี้เก็บข้อมูลจาก PLC ได้ไหม” เรายังไม่เคยตอบกลับไปตรง ๆ ด้วยคำว่า “ได้” หรือ “ไม่ได้” ได้เลยสักครั้ง เพราะสิ่งที่ถูกกำหนดไว้จริง ๆ ในงานเก็บข้อมูลจาก PLC ไม่ใช่ว่าทำได้หรือทำไม่ได้ แต่คือ จะผ่านเส้นทางใดใน 4 เส้นทางที่มีอยู่ เมื่อเส้นทางถูกกำหนดแล้ว ทั้งค่าใช้จ่าย ขีดจำกัดของค่าที่เก็บได้ และสิ่งที่ต้องไปสอบถามผู้ผลิตเครื่องจักร ก็แทบจะถูกกำหนดตามมาโดยอัตโนมัติ และต้นเหตุที่แท้จริงของการที่ใบเสนอราคาต่างกันคนละหลัก ก็ไม่ใช่การเลือกว่าจะใช้ OPC UA หรือ Modbus จำนวนแท็ก รอบการเก็บข้อมูล และการรับประกันของผู้ผลิตเครื่องจักร สามอย่างนี้ต่างหาก

สิ่งที่ถูกกำหนดไว้จริง ๆ ในการเก็บข้อมูลจาก PLC คือ “เส้นทาง”

เวลาวางใบเสนอราคาเรียงกันแล้วพบว่า โรงงานเดียวกัน จำนวนเครื่องเท่ากัน แต่ราคาต่างกัน 2 เท่า 3 เท่า ปรากฏการณ์นี้ไม่ใช่เรื่องแปลก คำอธิบายที่มักได้รับคือความต่างของมาตรฐานการสื่อสาร แต่พอเปิดรายละเอียดออกมาดู ส่วนใหญ่กลับไม่ใช่แบบนั้น สิ่งที่ต่างกันคือเส้นทางที่แต่ละเจ้าตั้งสมมติฐานเอาไว้

เส้นทางมีอยู่เพียง 4 เส้นทางเท่านั้น อ่านตรงจาก PLC ที่รองรับ Ethernet อยู่เดิม ใช้ฟังก์ชัน OPC UA Server ที่มีอยู่ในตัว PLC เพิ่มตัวแปลงให้ PLC รุ่นเก่าที่มีแต่พอร์ตอนุกรม และวัดจากภายนอกโดยไม่แตะ PLC เลย ทั้งสี่เส้นทางนี้ปะปนกันอยู่ในโรงงานเดียวกันถือเป็นเรื่องปกติ ด้วยเหตุนี้ คำถามที่ว่า “โรงงานของเราเก็บข้อมูลได้ไหม” จึงตั้งอยู่บนความละเอียดที่ไม่ตรงกันตั้งแต่แรก เพราะเส้นทางถูกกำหนดเป็นรายเครื่อง และราคาต่อหน่วยกับขีดจำกัดก็ถูกกำหนดตามเส้นทางนั้น

สำหรับภาพรวมของการทำ IoT ในโรงงานและลำดับว่าควรเริ่มลงมือจากตรงไหน เราสรุปไว้ในภาพรวมการนำระบบมอนิเตอร์ IoT มาใช้ในโรงงาน ส่วนบทความนี้จะเจาะลึกเฉพาะจุดเดียวคือ “การดึงค่าออกมาจาก PLC” ลงไปถึงระดับของเส้นทางและค่าใช้จ่าย

เส้นทางที่ 1 อ่านตรงจาก PLC ที่รองรับ Ethernet อยู่เดิม (MC Protocol / FINS / S7 / EtherNet/IP)

ทุกวันนี้เส้นทางที่มีจำนวนมากที่สุดทั้งในและนอกประเทศคือเส้นทางนี้ เกตเวย์ IoT หรืออุปกรณ์เอดจ์จะคุยกับ PLC ที่มีพอร์ต Ethernet อยู่แล้วด้วยโปรโตคอลเฉพาะของแต่ละยี่ห้อ แล้วอ่านหน่วยความจำอุปกรณ์ของ PLC โดยตรง

• ถ้าเป็นซีรีส์ MELSEC ของ Mitsubishi Electric จะใช้ MC Protocol
• ถ้าเป็น Omron จะใช้ FINS
• ถ้าเป็น Siemens จะใช้ S7 (S7comm)
• ถ้าเป็น Rockwell Automation จะใช้ EtherNet/IP (CIP)

ทั้งหมดนี้ล้วนดึงค่าที่ PLC ถืออยู่ออกมาตรง ๆ ในรูปแบบอย่าง “อ่าน 10 เวิร์ดเริ่มจาก D รีจิสเตอร์หมายเลข 100” หรือ “ระบุชื่อแท็กแล้วอ่าน”

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

ข้อเสียคือ ความหมายของแท็กไม่ได้อยู่ในรูปที่เครื่องอ่านเข้าใจได้ ว่าใน D100 มีอะไรอยู่นั้นไม่ได้ถูกเขียนไว้ที่ใดใน PLC เลย มันอยู่ในเอกสารออกแบบ อยู่ในคอมเมนต์ของแลดเดอร์ หรือไม่ก็อยู่ในความทรงจำของช่างซ่อมบำรุงรุ่นเก๋า ในมุมของเกตเวย์ D100 เป็นเพียงจำนวนเต็ม 16 บิตตัวหนึ่ง เครื่องไม่มีทางตัดสินได้เองว่าหน่วยเป็นมิลลิวินาทีหรือวินาที เป็นยอดสะสมของจำนวนผลิตหรือเป็นยอดเฉพาะกะนั้น และเมื่อค่าเป็น 0 นั้น หมายถึง “หยุดอยู่” หรือ “สื่อสารไม่ได้” กันแน่

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

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

เส้นทางที่ 2 ใช้ฟังก์ชัน OPC UA Server ของ PLC

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

ความต่างที่ชี้ขาดเมื่อเทียบกับเส้นทางที่ 1 คือ ไม่ได้มาแค่ค่า แต่มีข้อมูลกำกับ (metadata) ติดมาด้วย

ข้อมูลบางส่วนที่ในเส้นทางที่ 1 ต้องให้คนคัดลอกลงทะเบียนเอง กลับมาอยู่บนฝั่งเซิร์ฟเวอร์ในรูปที่เครื่องอ่านเข้าใจได้ นี่คือเหตุผลสำคัญที่สุดที่ทำให้เลือก OPC UA โดยเฉพาะ คุณภาพ (status) นั้นส่งผลกับการใช้งานจริงมาก เพราะเมื่อค่าเป็น 0 ฝั่งผู้รับจะแยกออกได้ว่า “เป็น 0 จริง ๆ” หรือ “อ่านค่าไม่ได้” ในเส้นทางที่ 1 เราแยกตรงนี้ไม่ได้ และมีกรณีที่การขาดการสื่อสารถูกวาดลงกราฟกลายเป็น “จำนวนผลิต 0” ไปเลย

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

ข้อเสียมี 3 ข้อ ข้อแรกคือ ภาระของ CPU เพราะ OPC UA Server ทำงานอยู่บน CPU ของ PLC จึงต้องแบ่งทรัพยากรกับการสแกนควบคุม สำหรับไลน์ที่กำลังเดินอยู่ ต้องตรวจสอบว่าเวลาสแกนเปลี่ยนไปอย่างไรก่อนและหลังเปิดใช้งาน ข้อที่สองคือ ค่าไลเซนส์ เพราะหลายรุ่นต้องซื้อไลเซนส์เพื่อเปิดใช้งาน และค่านี้จะสะสมขึ้นตามจำนวนเครื่อง ข้อที่สามคือ รุ่นที่รองรับมีจำกัด PLC ที่ติดตั้งไว้เมื่อ 10 ปีหรือ 20 ปีก่อนย่อมไม่มีฟังก์ชันนี้ตั้งแต่ต้น

ในด้านการทำมาตรฐานที่ระดับฟิลด์ OPC Foundation กำลังผลักดัน OPC UA FX (Field eXchange) อยู่ ตามข้อมูลที่เปิดเผยไว้ ข้อกำหนดส่วน Controller-to-Controller (C2C) เสร็จสมบูรณ์แล้ว และ ณ เดือนมิถุนายน 2026 อยู่ในขั้นเตรียมรีลีสแคนดิเดตของส่วนขยาย Controller-to-Device (C2D) โดย C2D มีเป้าหมายครอบคลุมการผนวกรวมอุปกรณ์โมชัน รีโมต I/O เซ็นเซอร์ และแอกชูเอเตอร์ มีรายงานว่าในวันที่ 16 ถึง 19 กุมภาพันธ์ 2026 ได้มีการจัดงานทดสอบการเชื่อมต่อระหว่างกัน (IOP) ที่สำนักงาน Beckhoff กรุงเบอร์ลิน และกำลังเตรียมกำแพงสาธิตแบบหลายผู้ผลิตสำหรับงาน SPS 2026 อย่างไรก็ตาม ช่วงเวลาของการรีลีสอย่างเป็นทางการและหมายเลขเวอร์ชันยังไม่มีการประกาศ ดังนั้นสำหรับโครงการที่กำลังวางแผนอยู่ตอนนี้ ขอให้หลีกเลี่ยงการออกแบบโดยตั้งสมมติฐานว่าจะใช้ C2D สิ่งที่ใช้ได้แน่นอน ณ ปัจจุบัน คือฟังก์ชัน OPC UA Server ที่มีอยู่เดิมมากกว่า

เส้นทางที่ 3 เพิ่มตัวแปลงให้ PLC รุ่นเก่าที่มีแต่พอร์ตอนุกรม

PLC ที่ไม่มีพอร์ต Ethernet มีออกมาแค่ RS-232C หรือ RS-485 ยังเหลืออยู่จำนวนไม่น้อยในโรงงานที่เดินเครื่องอยู่จริง กรณีนี้จะเพิ่มยูนิตที่แปลงสัญญาณอนุกรมเป็น Modbus TCP หรือรูปแบบอื่นเข้าไปในตู้คอนโทรล

Modbus มีการอิมพลีเมนต์ที่เรียบง่าย อุปกรณ์ที่รองรับมีเยอะ และยูนิตแปลงก็ราคาไม่แพง แต่แลกมาด้วยข้อจำกัดเชิงคุณสมบัติ 3 ข้อ

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

ข้อที่สองคือวิธีออกแบบการอ่านทำให้ความเร็วต่างกันคนละหลัก การอ่านรีจิสเตอร์ที่เรียงต่อเนื่องกันเป็นบล็อกด้วยคำขอเดียว กับการวนอ่านทีละจุดแบบเดี่ยว ๆ ให้ประสิทธิภาพต่างกันอย่างสิ้นเชิง การรวบเป็นบล็อกเร็วกว่าอย่างเทียบกันไม่ติด บนบัสอนุกรมอย่าง RS-485 เวลาที่ใช้ในการวิ่งไปกลับหนึ่งรอบและการแย่งใช้บัสเป็นตัวกำหนดเพดานความเร็ว การลดจำนวนคำขอลงจึงเป็นวิธีเร่งความเร็วเพียงวิธีเดียว งานที่มีคนบอกว่า “Modbus ช้า” ส่วนใหญ่ไม่ได้ช้าเพราะโปรโตคอล แต่เป็นเพราะวิธีอ่านกลายเป็นการวนอ่านทีละจุดเท่านั้นเอง การออกแบบส่วนนี้ขึ้นอยู่กับว่ารีจิสเตอร์เรียงเลขต่อเนื่องกันหรือไม่ จึงต้องมีทะเบียนข้อมูลว่า “แอดเดรสไหนเก็บอะไร” ไว้ก่อน เช่นเดียวกับเส้นทางที่ 1

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

เส้นทางที่ 4 วัดจากภายนอกโดยไม่แตะ PLC

เครื่องเดี่ยวที่ไม่มี PLC เครื่องที่ทำงานด้วยมือ และ “เครื่องจักรที่แตะ PLC ไม่ได้เพราะติดเงื่อนไขการรับประกันของผู้ผลิต” สามกลุ่มนี้เหลือทางเลือกเดียวคือวัดจากภายนอก

วิธีหลักมี 3 อย่าง

• การแยกสัญญาณจากไฟสามสี (signal tower) แยกสัญญาณการติดของไฟเขียว เหลือง แดง ออกมาอ่าน แล้วตัดสินสถานะเดินเครื่อง/หยุด/ผิดปกติ เนื่องจากเป็นเพียงการแยกสายไฟที่มีอยู่เดิม จึงไม่เกิดการเปลี่ยนแปลงใด ๆ กับฝั่ง PLC เลย
• การนับด้วยโฟโตอิเล็กทริกเซ็นเซอร์ วางเซ็นเซอร์ไว้ตรงตำแหน่งที่ชิ้นงานหรือผลิตภัณฑ์สำเร็จรูปวิ่งผ่าน แล้วนับจำนวนครั้งที่ผ่านเป็นจำนวนผลิต
• เซ็นเซอร์วัดกระแส วัดกระแสของสปินเดิลหรือมอเตอร์ แล้วถือว่าช่วงเวลาที่เกินค่าเกณฑ์ (threshold) คือเวลาเดินเครื่อง ถ้าเป็นแบบแคลมป์ก็ติดตั้งได้โดยไม่ต้องตัดสายไฟ

สิ่งที่เก็บได้จากเส้นทางนี้คือ สถานะเดินเครื่อง/หยุด และจำนวนผลิตเท่านั้น รหัสสาเหตุการหยุดเก็บไม่ได้ ต่อให้รู้ว่าไฟสามสีเปลี่ยนเป็นสีแดง ก็แยกไม่ออกว่าเป็นเพราะชิ้นงานติดขัด วัสดุหมด หรือฮีตเตอร์ผิดปกติ อีกทั้งยังแยกย่อยรายละเอียดของรอบเวลา (cycle time) ไม่ได้ด้วย เช่น “ใช้เวลากี่วินาทีในการแปรรูป กี่วินาทีในการลำเลียง” เพราะสิ่งที่มองเห็นจากภายนอกมีเพียงผลลัพธ์ ส่วนสถานะภายในของเครื่องจักรนั้นมองไม่เห็น

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

เมื่อวางทั้ง 4 เส้นทางเรียงกัน จะได้ภาพแบบนี้

สิ่งที่เปลี่ยนมาตรฐานการสื่อสารแล้วก็ยังเก็บไม่ได้ 3 ข้อ

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

เหตุผลที่ 1 ค่าที่ต้องการไม่มีอยู่ในแลดเดอร์

ทางตันที่พบบ่อยที่สุดคือข้อนี้

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

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

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

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

เหตุผลที่ 2 รอบการเก็บหยาบกว่ารอบสแกน

ข้อที่สองเป็นเรื่องของรอบเวลา ตรงนี้ถ้าไม่ดูเป็นตัวเลขก็จะจับความรู้สึกไม่ได้

PLC วนทำงานอ่านอินพุต ประมวลผล และอัปเดตเอาต์พุตด้วยความเร็วสูง หนึ่งรอบนี้คือรอบสแกน ซึ่งขึ้นอยู่กับขนาดของโปรแกรม แต่เครื่องจักรที่วนอยู่ที่ราว ๆ 10ms นั้นไม่ใช่เรื่องแปลก ในทางกลับกัน รอบการโพลลิ่งของฝั่งเก็บข้อมูลมักถูกตั้งไว้ที่ 1,000ms (1 วินาที) ด้วยข้อจำกัดของจำนวนแท็กและเครือข่าย

1,000ms ÷ 10ms = 100 เท่า เท่ากับว่าฝั่งเก็บข้อมูลมองเห็นค่าเพียงครั้งเดียวในระหว่างที่ PLC สแกนไป 100 รอบ

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

ที่หนักกว่านั้นคือการหยุดสั้น ๆ

การหยุด 20 วินาทีนั้น ถ้าใช้รอบ 1 วินาทีก็สุ่มตัวอย่างสถานะหยุดได้หลายครั้ง จึงถูกบันทึกอย่างแน่นอน แต่การหยุด 3 วินาทีนั้น ขึ้นอยู่กับจังหวะการสุ่มตัวอย่าง จึงเป็นไปได้ที่เครื่องจะกลับมาเดินโดยที่ไม่เคยถูกสังเกตเห็นในสถานะหยุดเลยแม้แต่ครั้งเดียว ถ้ามีความต้องการว่า อยากเห็นการหยุดสั้น ๆ (minor stoppage) แล้วเสนอการจัดวางแบบทั่วไปที่ใช้รอบ 1 วินาทีไปตรง ๆ ผลที่ได้คือการหยุดสั้น ๆ ซึ่งเป็นสิ่งที่อยากเห็นที่สุดกลับเป็นสิ่งเดียวที่หลุดไป

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

เหตุผลที่ 3 การรับประกันของผู้ผลิตเครื่องจักรและความเป็นไปได้ในการดัดแปลง

ข้อที่สามไม่ใช่เรื่องเทคนิค แต่เป็นเรื่องสัญญา และในโรงงานที่เดินเครื่องอยู่จริง ข้อนี้กลายเป็นข้อจำกัดที่แข็งแรงที่สุด

เครื่องจักรที่ผู้ผลิตส่งมอบมามักมีข้อจำกัดเรื่องการดัดแปลงติดมาด้วย ปัญหาคือขอบเขตของข้อจำกัดนั้นไม่ได้จำกัดอยู่แค่ “การแก้แลดเดอร์” เท่านั้น แม้จะตั้งใจว่าจะแค่อ่านค่า แต่ในทางปฏิบัติอาจต้องทำงานต่อไปนี้

• การเพิ่มยูนิตสื่อสาร ซึ่งกินสล็อตในตู้คอนโทรล
• การเปลี่ยนพารามิเตอร์การสื่อสารของ PLC เช่น หมายเลขสถานี IP address และการเปิดพอร์ต
• การเปิดใช้ฟังก์ชัน OPC UA Server และการใส่ไลเซนส์
• การเดินสายเพิ่มภายในตู้ และการเจาะรูที่ประตูตู้

ว่าสิ่งเหล่านี้อยู่ในขอบเขตของการรับประกันถึงระดับไหน ขึ้นอยู่กับสัญญาและนโยบายของผู้ผลิตแต่ละราย มีทั้งผู้ผลิตที่บอกว่า “ถ้าแค่อ่านค่าก็ไม่มีปัญหา” และผู้ผลิตที่บอกว่า “การเพิ่มยูนิตสื่อสารต้องให้ทีมของเราทำเท่านั้น”

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

ดังนั้นในทางปฏิบัติ เราจึง วางการสอบถามผู้ผลิตเครื่องจักรไว้เป็นรายการแรกของแผนงาน การรอคำตอบหลายสัปดาห์ไม่ใช่เรื่องแปลก และหากคำตอบคือ “พนักงานของเราจะเข้าไปดำเนินการที่หน้างานเอง” ค่าแรงส่วนนั้นก็จะขึ้นไปอยู่บนใบเสนอราคา เหตุที่การประมาณการด้วยโรงงานจำลองซึ่งจะกล่าวถึงต่อไปลงบัญชี ค่าดำเนินการของผู้ผลิตเครื่องจักร 35,000 บาทต่อเครื่อง ไว้ในเส้นทางที่ 2 ก็เพื่อสะท้อนความจริงข้อนี้ การมีหรือไม่มีบรรทัดนี้เพียงบรรทัดเดียว ทำให้ราคาต่อเครื่องของเส้นทางที่ 2 เปลี่ยนจาก 25,000 บาทเป็น 60,000 บาท

3 ตัวแปรที่ทำให้ใบเสนอราคาต่างกันคนละหลัก คือจำนวนแท็ก รอบการเก็บ และการรับประกัน

เราจะสรุปเนื้อหาทั้งหมดข้างต้นให้เหลือ 3 ตัวแปรในมุมของใบเสนอราคา เวลาที่ราคาของผู้ขายแต่ละเจ้าไม่ตรงกัน ต้นเหตุมักอยู่ที่ข้อใดข้อหนึ่งใน 3 ข้อนี้

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

ในเงื่อนไขจำลองของบทความนี้ เราวางชั้นราคาไว้ดังนี้

เส้นแบ่งอยู่ระหว่าง 50 กับ 51 ถ้า 50 แท็กคือ 180,000 บาท ถ้า 51 แท็กคือ 250,000 บาท ความไม่ต่อเนื่องที่ว่า เพิ่มขึ้นเพียง 1 แท็กแต่ราคาขึ้น 70,000 บาท อยู่ตรงนี้

นี่ไม่ใช่เรื่องบนกระดาษ จำนวนแท็กของแนวทาง A ที่จะกล่าวถึงคือ 8 เครื่อง × 4 ตัวแปร = 32 แท็ก ซึ่งอยู่ในชั้นไม่เกิน 50 แท็ก ส่วนแนวทาง B คือ 20 เครื่อง × 4 ตัวแปร บวก 4 เครื่อง × 2 ตัวแปร = 80 + 8 = 88 แท็ก จึงขยับขึ้นไปอยู่ชั้น 51 ถึง 250 แท็ก โครงสร้างคือ นอกเหนือจากส่วนเพิ่มโดยตรงจากการเพิ่มเครื่องจักรอีก 16 เครื่อง เช่น เกตเวย์และงานติดตั้งแล้ว ยังเกิดส่วนต่าง 70,000 บาทจากชั้นไลเซนส์ของซอฟต์แวร์เพียงอย่างเดียวอีกด้วย

ดังนั้น สิ่งที่ควรยืนยันในขั้นกำหนดความต้องการจึงไม่ใช่ “จะติดกี่เครื่อง” แต่คือ “จะเก็บกี่ตัวแปรต่อหนึ่งเครื่อง และรวมแล้วกี่แท็ก” ถ้าขอใบเสนอราคาเปรียบเทียบทั้งที่ยังตอบคำถามนี้ไม่ได้ แต่ละเจ้าก็จะเสนอราคาบนจำนวนแท็กที่ตนสมมติขึ้นเอง และการเปรียบเทียบก็จะไม่เกิดขึ้นจริง

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

ในทางปฏิบัติ การออกแบบที่ ไม่ตั้งรอบเวลาเดียวกันให้ทุกแท็ก จะได้ผลดี ตัวแปรที่อยากจับการเปลี่ยนแปลงระยะสั้นอย่างสถานะเดินเครื่อง/หยุดให้ใช้รอบสั้น ส่วนตัวแปรที่ใช้ค่าสะสมก็เพียงพออย่างยอดสะสมของจำนวนผลิตให้ใช้รอบยาว จัดสรรรอบเวลาเป็นรายตัวแปรแบบนี้ และถ้าใช้ subscription ของ OPC UA ได้ แท็กที่ไม่มีการเปลี่ยนแปลงก็จะไม่ก่อให้เกิดการสื่อสารตั้งแต่แรก

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

ทั้ง 3 ข้อล้วนไม่ใช่เรื่องของมาตรฐานการสื่อสาร ไม่ว่าจะเลือก OPC UA หรือเลือก Modbus จำนวนแท็กก็ไม่เปลี่ยน และข้อกำหนดการรับประกันของผู้ผลิตเครื่องจักรก็ไม่เปลี่ยน ข้อสรุปตรงนี้คือ ส่วนต่างของใบเสนอราคาไม่ได้เกิดจากมาตรฐาน แต่เกิดจาก 3 ตัวแปรนี้ สำหรับการจัดระเบียบโครงสร้างค่าใช้จ่ายของ IoT ในโรงงานให้กว้างขึ้นโดยแบ่งเป็น 5 ชั้น เราเขียนไว้ในแยกค่าใช้จ่าย IoT ในโรงงานออกเป็น 5 ชั้น

แยกส่วนค่าใช้จ่ายและการคืนทุนด้วยโรงงานจำลอง

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

เงื่อนไขของโรงงานจำลอง

การแบ่งกลุ่มสอดคล้องกับเส้นทางโดยตรง กลุ่ม A คือเส้นทางที่ 1 กลุ่ม B คือเส้นทางที่ 2 ซึ่งเกิดการตรวจสอบการรับประกันและค่าดำเนินการเพราะเป็นเครื่องที่ผู้ผลิตส่งมอบ กลุ่ม C คือเส้นทางที่ 3 และกลุ่ม D คือเส้นทางที่ 4 รวม 10 + 6 + 4 + 4 เป็น 24 เครื่อง

สภาพจริงของการหยุดเครื่องเป็นดังนี้

บรรทัดสุดท้ายคือสมมติฐานที่สำคัญที่สุดของบทความนี้ การหยุดของกระบวนการที่ไม่ใช่คอขวดนั้นไม่กลายเป็นกำไรที่สูญเสียไป เพราะต่อให้กระบวนการนั้นหยุดไป 1 ชั่วโมง ก็จะถูกดูดซับด้วยงานระหว่างทำและกำลังการผลิตที่เหลืออยู่ของกระบวนการอื่น จนปริมาณการส่งมอบสุดท้ายไม่เปลี่ยนแปลง เวลาหยุดของอีก 16 เครื่องที่เหลือมีอยู่ 380 − 240 = 140 ชั่วโมง แต่เหตุที่เราไม่แปลงตัวเลขนี้เป็นตัวเงินก็มาจากเหตุผลนี้เอง

เพื่อเป็นข้อมูลอ้างอิง ขอยกสถิติของภาคการผลิตไทยในช่วงนี้ มีรายงานว่า ตามการเปิดเผยของสำนักงานเศรษฐกิจอุตสาหกรรม (OIE) กระทรวงอุตสาหกรรม ดัชนีผลผลิตอุตสาหกรรม (MPI) ของเดือนมิถุนายน 2026 อยู่ที่ −3.10% เมื่อเทียบกับเดือนเดียวกันของปีก่อน ซึ่งเป็นช่วงการลดลงที่มากที่สุดนับตั้งแต่เดือนพฤศจิกายน 2025 ส่วนไตรมาสที่ 2 ของปี 2026 อยู่ที่ −1.79% และอัตราการใช้กำลังการผลิตเฉลี่ยอยู่ที่ 57.47% โดยระบุว่ายานยนต์และปิโตรเลียมเป็นตัวฉุด ขณะที่สินค้าจำเป็นในชีวิตประจำวันอย่างน้ำตาล ผงซักฟอก สบู่ และเครื่องสำอาง มีแนวโน้มฟื้นตัว

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

การประเมินผลที่ได้ ซึ่งใช้ร่วมกันทั้งสองแนวทาง

เมื่อเก็บข้อมูลได้แล้วอะไรจะเปลี่ยนไป เนื้อหาของผลที่ได้คือ “เวลาหยุดเครื่องเองสั้นลง” ซึ่งแยกออกเป็น 2 ส่วน

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

การระบุสาเหตุ คือเวลาตั้งแต่วิ่งไปถึงหน้าเครื่องจนตัดสินได้ว่าเกิดอะไรขึ้น ถ้ามีประวัติของรหัสสาเหตุการหยุดและรอบเวลา ก็ดูบนหน้าจอได้ว่าก่อนหน้านั้นเกิดอะไรขึ้น 18 นาทีจึงเหลือ 8 นาที พูดกลับกันคือ การย่นเวลาส่วนนี้มีเงื่อนไขว่าต้องเก็บรหัสสาเหตุการหยุดได้ สำหรับเครื่องจักรที่ใช้ได้เพียงเส้นทางที่ 4 จะคาดหวังการย่นเวลา 10 นาทีส่วนนี้ไม่ได้

รวมแล้วย่นได้ 20 นาที ต่อหนึ่งครั้ง นำไปคูณกับจำนวนครั้งของการหยุดของคอขวด

• 320 ครั้ง × 20 นาที = 6,400 นาทีต่อปี
• 6,400 นาที ÷ 60 = 106.67 ชั่วโมงต่อปี
• 106.67 ชั่วโมง × 3,200 บาท = 341,333 บาทต่อปี
• ตลอด 5 ปีคือ 1,706,667 บาท

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

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

แนวทาง A จำกัดเฉพาะคอขวด 8 เครื่อง

เป้าหมายคือกลุ่ม A 5 เครื่อง กลุ่ม B 2 เครื่อง และกลุ่ม C 1 เครื่อง รวม 8 เครื่อง เก็บ 4 ตัวแปรต่อเครื่อง

จำนวนแท็กคือ 8 เครื่อง × 4 ตัวแปร = 32 แท็ก ซึ่งอยู่ในชั้นไม่เกิน 50 แท็ก

เหตุที่เกตเวย์ใช้เพียงตัวเดียวก็เพราะรุ่นนี้รองรับได้สูงสุด 8 โหนดต่อหนึ่งตัว กลุ่ม A 5 เครื่องจึงใช้ตัวเดียวพอ ขั้นบันไดที่ว่า จะ 5 เครื่องหรือ 8 เครื่อง ราคา 45,000 บาทก็ไม่เปลี่ยน แต่พอถึงเครื่องที่ 9 จะต้องเพิ่มตัวที่สอง อยู่ตรงนี้ เวลาถกกันว่าจะเพิ่มเครื่องอีกหนึ่งเครื่องดีหรือไม่ ขอให้ตรวจสอบก่อนว่าเรากำลังยืนอยู่ฝั่งไหนของขั้นบันไดนี้

ค่าใช้จ่ายดำเนินงานรายปีเป็นดังนี้

สรุปยอด 5 ปี

• ค่าใช้จ่ายรวม 5 ปี = 542,000 + 90,000×5 = 992,000 บาท
• ผลที่ได้ตลอด 5 ปี = 1,706,667 บาท
• ผลประโยชน์สุทธิ 5 ปี = 1,706,667 − 992,000 = 714,667 บาท
• ระยะเวลาคืนทุนอย่างง่าย = 542,000 ÷ (341,333 − 90,000) = 2.16 ปี หรือ 25.9 เดือน

ยังมีอีกสัดส่วนหนึ่งในโครงสร้างค่าใช้จ่ายที่อยากให้ดูไว้

ส่วนที่ดึงค่าออกมาจาก PLC ที่หน้างานจริง คิดเป็นเพียงครึ่งเดียวของค่าใช้จ่ายเริ่มต้นเท่านั้น อีกครึ่งหนึ่งที่เหลือคือเซิร์ฟเวอร์และเครือข่าย ซึ่งเป็น “นอกหน้างาน” ถ้าไม่รู้จุดนี้แล้วทุ่มเวลาไปกับการต่อรองว่า “ช่วยลดราคาต่อหน่วยของเกตเวย์ให้หน่อย” ผลที่ได้ก็จำกัด เพราะในความเป็นจริง ตัวเกตเวย์ของเส้นทางที่ 1 อยู่ที่ 45,000 บาท ซึ่งยังไม่ถึง 1 ใน 10 ของค่าใช้จ่ายเริ่มต้น 542,000 บาทด้วยซ้ำ

แนวทาง B ติดครบทั้ง 24 เครื่อง

เป็นแนวทางที่ติดครบทุกเครื่อง โดยใช้เส้นทางที่ 1 กับกลุ่ม A 10 เครื่อง เส้นทางที่ 2 กับกลุ่ม B 6 เครื่อง เส้นทางที่ 3 กับกลุ่ม C 4 เครื่อง และเส้นทางที่ 4 กับกลุ่ม D 4 เครื่อง

จำนวนแท็กคือ กลุ่ม A ถึง C รวม 20 เครื่อง × 4 ตัวแปร = 80 แท็ก และกลุ่ม D 4 เครื่อง × 2 ตัวแปร = 8 แท็ก รวมเป็น 88 แท็ก เนื่องจากเกินชั้นไม่เกิน 50 แท็ก เซิร์ฟเวอร์เก็บข้อมูลและการแสดงผลจึงเป็น 250,000 บาท ส่วนต่าง 70,000 บาทจากแนวทาง A เกิดจากการข้ามชั้นราคานี้

เกตเวย์ใช้ 2 ตัวสำหรับกลุ่ม A 10 เครื่อง เพราะเกินขีดจำกัดการรองรับที่ 8 โหนด

ค่าใช้จ่ายดำเนินงานรายปี

สรุปยอด 5 ปี

• ค่าใช้จ่ายรวม 5 ปี = 1,203,000 + 123,000×5 = 1,818,000 บาท
• ผลที่ได้ตลอด 5 ปี = 1,706,667 บาท ซึ่งเท่ากับแนวทาง A
• ผลประโยชน์สุทธิ 5 ปี = 1,706,667 − 1,818,000 = −111,333 บาท ซึ่งขาดทุน
• ระยะเวลาคืนทุนอย่างง่าย = 1,203,000 ÷ (341,333 − 123,000) = 5.51 ปี หรือ 66.1 เดือน

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

ส่วนต่างคือ 826,000 บาท และสิ่งที่แบ่งสองแนวทางออกจากกันไม่ใช่มาตรฐานการสื่อสาร

วางสองแนวทางเรียงกัน

ส่วนต่างของผลประโยชน์สุทธิ 5 ปีคือ 714,667 − (−111,333) = 826,000 บาท

ยอด 826,000 บาทนี้ตรงกับส่วนต่างของค่าใช้จ่ายรวม 5 ปี ซึ่งคือ 1,818,000 − 992,000 = 826,000 บาท ซึ่งเป็นเรื่องธรรมดา เพราะมูลค่าผลที่ได้ของทั้งสองแนวทางเท่ากัน เมื่อผลที่ได้ไม่เปลี่ยนแต่ค่าใช้จ่ายเพิ่มขึ้นอย่างเดียว ส่วนต่างของผลประโยชน์สุทธิก็คือส่วนต่างของค่าใช้จ่ายนั่นเอง

บรรทัดเดียวที่ควรเขียนลงในเอกสารขออนุมัติคือบรรทัดนี้

สิ่งที่แบ่งแนวทาง A กับแนวทาง B ออกจากกัน ไม่ใช่มาตรฐานการสื่อสาร และไม่ใช่ยี่ห้อของ PLC แต่คือคำถามเดียวว่า “เมื่อเครื่องจักรตัวนั้นหยุด มันกลายเป็นการสูญเสียยอดขายจริงหรือไม่”

ในวงสนทนาเรื่องใบเสนอราคา การถกเถียงมักไปกระจุกอยู่ที่ว่าจะเลือก OPC UA หรือ Modbus และจะเลือกเกตเวย์ตัวไหน แต่สิ่งที่ขยับตัวเงินมากที่สุดบนเงื่อนไขจำลองนี้กลับเป็นวิธีเลือกเครื่องจักรเป้าหมาย เมื่อเทียบกับราคาต่อหน่วยของตัวเกตเวย์ที่ 45,000 บาท ตัวเงินที่การจำกัดขอบเขตเป้าหมายขยับได้คือ 826,000 บาท

การวิเคราะห์ความไว 3 ข้อ

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

ความไวข้อที่ 1 กรณีกำไรที่สูญเสียต่อการหยุด 1 ชั่วโมงเปลี่ยนจาก 3,200 เป็น 1,600 บาท

• ผลที่ได้ต่อปี = 106.67 ชั่วโมง × 1,600 บาท = 170,667 บาทต่อปี
• ระยะเวลาคืนทุนของแนวทาง A = 542,000 ÷ (170,667 − 90,000) = 6.72 ปี หรือ 80.6 เดือน

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

ความไวข้อที่ 2 กรณีการย่นเวลาตรวจพบและระบุสาเหตุทำได้เพียง 10 นาที ไม่ถึง 20 นาที

• ผลที่ได้ต่อปี = 320 ครั้ง × 10 นาที = 3,200 นาที = 53.33 ชั่วโมง จากนั้น 53.33 ชั่วโมง × 3,200 บาท = 170,667 บาทต่อปี

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

สาเหตุที่สมจริงของการที่ย่นได้เพียง 10 นาที อยู่ที่ฝั่งการระบุสาเหตุ ในเครื่องจักรที่ไม่มีรหัสสาเหตุการหยุดอยู่ในแลดเดอร์ตามเหตุผลที่ 1 หรือเครื่องที่ใช้ได้เพียงเส้นทางที่ 4 การย่นเวลาระบุสาเหตุจาก 18 นาทีเหลือ 8 นาทีจะไม่เกิดขึ้นจริง ความสัมพันธ์ที่ว่า ถ้าละเลยการตรวจสอบตามเหตุผลที่ 1 ผลที่ได้จะเหลือครึ่งเดียว อยู่ตรงนี้

ความไวข้อที่ 3 กรณีคอขวดมี 4 เครื่อง ไม่ใช่ 8 เครื่อง

เรียงสมมติฐานใหม่ การหยุดของคอขวดคือ 120 ชั่วโมง จำนวนครั้งคือ 160 ครั้ง ส่วนที่ย่นได้คือ 160 ครั้ง × 20 นาที = 3,200 นาที = 53.33 ชั่วโมง และผลที่ได้คือ 53.33 ชั่วโมง × 3,200 บาท = 170,667 บาทต่อปี

ถ้ากำหนดองค์ประกอบของ 4 เครื่องเป้าหมายเป็นกลุ่ม A 3 เครื่อง กลุ่ม B 1 เครื่อง และกลุ่ม C 0 เครื่อง ค่าใช้จ่ายเริ่มต้นจะเป็นดังนี้

ค่าใช้จ่ายดำเนินงานรายปีคือ 70,000 บาท

• ระยะเวลาคืนทุนอย่างง่าย = 390,000 ÷ (170,667 − 70,000) = 3.87 ปี หรือ 46.5 เดือน

ตรงนี้คือความย้อนแย้ง ระยะเวลาคืนทุนของแนวทาง A ที่ 8 เครื่องคือ 2.16 ปี ส่วนแนวทางนี้ที่ 4 เครื่องคือ 3.87 ปี ลดเป้าหมายลงครึ่งหนึ่ง แต่การคืนทุนกลับช้าลง

สาเหตุคือค่าใช้จ่ายคงที่ เซิร์ฟเวอร์เก็บข้อมูลและการแสดงผลนั้น จะ 16 แท็กหรือ 32 แท็กก็เป็น 180,000 บาทเท่ากัน งานเครือข่ายเองก็ไม่ได้แปรผันตรงกับจำนวนเครื่องอย่างสมบูรณ์ ในทางกลับกัน ผลที่ได้ลดลงครึ่งหนึ่งตามจำนวนครั้งเกือบเป็นสัดส่วน ตัวเศษซึ่งคือผลที่ได้ลดลงครึ่งหนึ่ง ส่วนตัวส่วนซึ่งคือค่าใช้จ่ายไม่ได้ลดลงครึ่งหนึ่ง ประสิทธิภาพจึงตกลง

ดังนั้น “ยิ่งจำกัดขอบเขตยิ่งได้เปรียบ” จึงไม่จริง คำกล่าวที่ถูกต้องคือ จำกัดขอบเขตลงมาถึงระดับที่ยังรวบรวมจำนวนครั้งของคอขวดได้มากพอจะเฉลี่ยค่าใช้จ่ายคงที่ให้บางลง แนวทาง A ที่ 8 เครื่องคือจุดที่อัดผลที่ได้เข้าไปได้มากที่สุดเมื่อเทียบกับค่าใช้จ่ายคงที่ ภายในขอบเขตที่ 32 แท็กยังอยู่ในชั้นไม่เกิน 50 แท็กซึ่งอยู่ที่ 180,000 บาท ถ้าลดลงอีก 1 เครื่องก็จะมีแต่ผลที่ได้ที่ลดลง ในทางกลับกัน ถ้าขยายเป้าหมายออกไปเรื่อย ๆ พอจำนวนแท็กเกิน 50 เมื่อใด เซิร์ฟเวอร์เก็บข้อมูลก็จะขยับขึ้นไปชั้น 250,000 บาท และพอจำนวนเครื่องที่ต่อในเส้นทางที่ 1 เกิน 8 เมื่อใด เกตเวย์ก็จะเพิ่มเป็นตัวที่สอง ขอให้ขีดเส้นโดยตระหนักถึงขั้นบันไดเหล่านี้

5 ข้อที่ต้องตรวจสอบก่อนในโรงงานที่ประเทศไทย

ก่อนเข้าสู่ขั้นออกแบบ ขอยกรายการที่ควรตรวจสอบที่หน้างานไว้ 5 ข้อ ถ้าวางแผนด้วยสมมติฐานชุดเดียวกับโรงงานในญี่ปุ่น งานจะมาหยุดชะงักตรงนี้

1. แหล่งจ่ายไฟ โดยพื้นฐานแล้วเกตเวย์และยูนิตแปลงจะรับไฟจากไฟควบคุมภายในตู้ แต่ตู้เดิมไม่จำเป็นต้องมีกำลังเหลือเสมอไป ต้องตรวจสอบความจุของยูนิตจ่ายไฟ DC24V ช่องเบรกเกอร์ที่ว่าง และมาตรการรับมือไฟตกไฟดับชั่วขณะ ในทำเลที่คุณภาพไฟฟ้าฝั่งโรงงานไม่นิ่ง จะเกิดสภาพที่อุปกรณ์เก็บข้อมูลดับไปเพียงลำพัง กลายเป็น “เครื่องจักรเดินอยู่ แต่ข้อมูลขาดหาย” และเนื่องจากข้อมูลที่ขาดหายแยกไม่ออกจากการหยุดเครื่องบนกราฟ มันจึงทำให้การรวมยอดอัตราการเดินเครื่องคลาดเคลื่อน ต้องเลือกทางใดทางหนึ่งระหว่างการติดตั้ง UPS หรือการทำให้ฝั่งเก็บข้อมูลแยกข้อมูลที่ขาดหายออกจากการหยุดเครื่องได้

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

3. การแยกเครือข่าย ว่าจะแบ่งฝั่งควบคุม (OT) กับฝั่งสารสนเทศ (IT) ตรงจุดใด ต้องตัดสินใจไว้ตั้งแต่ตอนเริ่มเก็บข้อมูล Modbus ของเส้นทางที่ 3 ไม่มีทั้งการยืนยันตัวตนและการเข้ารหัส ส่วนโปรโตคอลเฉพาะยี่ห้อของเส้นทางที่ 1 ก็มีจำนวนมากที่ออกแบบมาในลักษณะเดียวกันคือ ถ้าเข้าถึงเครือข่ายได้ก็อ่านได้ แนวทางพื้นฐานคือวางเกตเวย์ไว้ที่เส้นแบ่ง แล้วจัดโครงสร้างให้ส่งขึ้นไปข้างบนเฉพาะข้อมูลที่จำเป็น หากจะใช้ LAN ไร้สายที่มีอยู่เดิม การวัดสภาพแวดล้อมคลื่นวิทยุจริงและการอยู่ร่วมกับทราฟฟิกของระบบผลิตก็เป็นรายการที่ต้องตรวจสอบเช่นกัน

4. การรับประกันของผู้ผลิตเครื่องจักร เป็นไปตามเหตุผลที่ 3 ถ้ามีเครื่องจักรที่ผู้ผลิตส่งมอบอย่างกลุ่ม B การขอตรวจสอบและการรอคำตอบจะใช้เวลา ขอให้วางไว้เป็นรายการแรกของแผนงาน ทั้งนี้ ขึ้นอยู่กับเนื้อหาของคำตอบ ก็อาจตัดสินใจลดเฉพาะเครื่องนั้นจากเส้นทางที่ 2 ลงมาเป็นเส้นทางที่ 4 คือวัดจากภายนอกก็ได้ ตัวแปรที่เก็บได้จะลดลง แต่ยังเก็บสถานะเดินเครื่อง/หยุดและจำนวนผลิตได้โดยที่การรับประกันยังคงอยู่

5. ใช้สิทธิหักรายจ่าย 200% ของ depa ได้หรือไม่ ประเทศไทยมีมาตรการหักรายจ่าย 200% สำหรับค่าใช้จ่ายด้านดิจิทัลของวิสาหกิจขนาดกลางและขนาดย่อม ขอสรุปเงื่อนไขดังนี้

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

และต่อให้ผ่านตรงนั้นมาได้ เพดานก็อยู่ที่ 300,000 บาท เมื่อเทียบกับค่าใช้จ่ายเริ่มต้นของแนวทาง A ที่ 542,000 บาท ต่อให้สมมติว่าใช้สิทธิได้ ส่วนที่เข้าข่ายก็ยังเป็นเพียงบางส่วน ตำแหน่งที่เหมาะสมของเรื่องนี้คือ ไม่ควรใส่เข้าไปเป็นสมมติฐานของการตัดสินใจลงทุน แต่เป็นรายการที่ตรวจสอบเฉพาะเมื่อเข้าเงื่อนไขเท่านั้น สำหรับการตัดสินขั้นสุดท้ายว่าใช้สิทธิได้หรือไม่ ขอให้ตรวจสอบกับสำนักงานบัญชีหรือผู้เชี่ยวชาญด้านภาษีเสมอ สิ่งที่บทความนี้แสดงได้มีเพียงขอบเขตของเงื่อนไขที่มีการเผยแพร่ไว้เท่านั้น

อนึ่ง ในฐานะข้อมูลแวดล้อมที่ส่งผลต่อระดับของค่าใช้จ่าย ค่าจ้างขั้นต่ำของไทยได้ปรับขึ้นเป็นวันละ 400 บาท จาก 372 บาทก่อนการปรับ ตั้งแต่วันที่ 1 กรกฎาคม 2025 ในกรุงเทพมหานครและเขตอุตสาหกรรมอย่างชลบุรีกับระยอง และยังคงอัตราเดิมเมื่อเข้าสู่ปี 2026 โดยทั่วประเทศอยู่ในช่วง 337 ถึง 400 บาท การทำงานแบบที่ให้คนเดินตรวจหน้างานเพื่อค้นหาการหยุด สอบถามสาเหตุ จดลงกระดาษ แล้วมาป้อนเข้าระบบทีหลัง จะหนักขึ้นทุกปีตามส่วนที่ค่าจ้างปรับขึ้นนี้ การตัดสินใจลงทุนเรื่องการเก็บข้อมูลจึงเป็นเรื่องที่ต้องมองควบคู่ไปกับแนวโน้มของต้นทุนแรงงานนี้ด้วย

ส่วนในบริบทที่กว้างขึ้นของนโยบายอุตสาหกรรม ธนาคารโลกได้ชูหัวข้อ “Advanced Green Manufacturing for Growth” ไว้ใน Thailand Economic Monitor ฉบับเดือนกุมภาพันธ์ 2026 การที่การยกระดับเครื่องจักรและการทำดิจิทัลกลายเป็นความสนใจของฝั่งนโยบาย ถือเป็นวัตถุดิบที่ใช้เป็นภูมิหลังในเอกสารอธิบายภายในองค์กรได้

ลำดับการดำเนินงานใน 90 วัน

นี่คือแนวทางที่เป็นจริง บนสมมติฐานว่าจะจำกัดขอบเขตเป้าหมาย

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

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

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

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

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

สัปดาห์ที่ 12 ถึง 13 กำหนดกฎการใช้งาน ทั้งผู้รับการแจ้งเตือนและลำดับการส่งต่อ กฎการป้อนรหัสสาเหตุการหยุด วิธีจัดการเมื่อข้อมูลขาดหาย และระยะเวลาเก็บรักษาข้อมูล ถ้าเปิดใช้แต่หน้าจอแสดงผลโดยไม่กำหนดสิ่งเหล่านี้ ภายใน 3 เดือนก็จะไม่มีใครเข้าไปดูอีก เป้าหมายไม่ใช่การสร้างหน้าจอ แต่คือการทำให้การหยุด 45 นาทีสั้นลง ขอให้เขียนเป็นข้อความว่าใครต้องทำอะไรภายในกี่นาที

ไม่จำเป็นต้องทำให้ครบทุกเครื่องภายใน 90 วัน การเดินให้ครบหนึ่งรอบด้วยจำนวนเครื่องที่จำกัดไว้ แล้วขยายไปยังกลุ่มถัดไปหลังจากวัดผลได้จริงแล้ว จะทำให้ทั้งความแม่นยำของใบเสนอราคารอบที่สองและคุณภาพของกฎการใช้งานดีขึ้น 8 เครื่องที่สมมติไว้ในแนวทาง A ก็คือขนาดของ “รอบแรก” นี้เอง

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

การเก็บข้อมูลจาก PLC จำเป็นต้องแก้แลดเดอร์หรือไม่

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

ระหว่าง OPC UA กับ Modbus ควรเลือกอะไร

ส่วนใหญ่แล้วมันไม่ใช่สิ่งที่เราเลือก แต่ ถูกกำหนดด้วยรุ่นของเครื่องฝั่งอุปกรณ์ ฟังก์ชัน OPC UA Server มีอยู่เฉพาะในรุ่นกลางและรุ่นสูงของยุคหลังเท่านั้น ส่วน PLC รุ่นเก่าที่มีออกมาแต่พอร์ตอนุกรมนั้นไม่มีตัวเลือกนี้ตั้งแต่ต้น การที่เส้นทางต่างกันไปในแต่ละเครื่องแล้วอยู่ปะปนกันภายในโรงงานเดียวถือเป็นเรื่องปกติ

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

อนึ่ง มีการนำไปเปรียบเทียบกับ MQTT Sparkplug อยู่บ้าง แต่ OPC UA กับ Sparkplug มีความสัมพันธ์แบบแบ่งบทบาทกันมากกว่าจะเป็นคู่แข่ง Sparkplug เป็นข้อกำหนดของ Eclipse Foundation ที่เพิ่มการทำมาตรฐานของ topic namespace เพย์โหลดที่มีชนิดข้อมูลกำกับ และใบรับรอง birth/death ซึ่งเป็นกลไกให้ฝั่งผู้รับแยกออกได้ตลอดเวลาว่าอุปกรณ์ออนไลน์อยู่หรือไม่ เข้าไปบน MQTT แบบธรรมดา อีกทั้งยังมีการผสมกันในรูปแบบ OPC UA PubSub over MQTT อยู่ด้วย แนวคิดที่ใกล้เคียงกับงานจริงคือการจัดระเบียบว่าใช้แยกกันตามชั้น คือชั้นที่ดึงค่าออกมาจากหน้างานกับชั้นที่กระจายข้อมูลขึ้นไปข้างบน ไม่ใช่การเลือก “อย่างใดอย่างหนึ่ง”

เครื่องจักรเก่าก็เก็บข้อมูลได้หรือไม่

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

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

ต้องใช้เกตเวย์ IoT กี่ตัว

ไม่ได้ถูกกำหนดด้วยจำนวนเครื่องจักร แต่ถูกกำหนดด้วยจำนวนโหนดที่รองรับได้และการแบ่งโซนของเครือข่าย เงื่อนไขจำลองของบทความนี้ตั้งอยู่บนรุ่นที่รองรับได้สูงสุด 8 โหนดต่อหนึ่งตัว จึงลงบัญชีไว้ที่ 1 ตัว คือ 45,000 บาท สำหรับ 5 เครื่องเป้าหมายของเส้นทางที่ 1 ในแนวทาง A และ 2 ตัว คือ 90,000 บาท สำหรับ 10 เครื่องเป้าหมายของเส้นทางที่ 1 ในแนวทาง B ขั้นบันไดคือ จะ 5 เครื่องหรือ 8 เครื่องก็ใช้ตัวเดียวพอ แต่พอถึงเครื่องที่ 9 จะต้องเพิ่มตัวที่สอง

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

การหยุดสั้น ๆ มองเห็นได้ด้วยการเก็บข้อมูลจาก PLC หรือไม่

ขึ้นอยู่กับรอบการเก็บ ถ้ากำหนดรอบการโพลลิ่งไว้ที่ 1 วินาที การหยุด 20 วินาทีจะถูกบันทึกอย่างแน่นอนเพราะกินเวลาคร่อมการสุ่มตัวอย่างหลายครั้ง แต่การหยุด 3 วินาทีอาจกลับมาเดินโดยไม่เคยถูกสังเกตเห็นเลยสักครั้ง ขึ้นอยู่กับจังหวะ ถ้าการสแกนของ PLC อยู่ที่ 10ms และการเก็บอยู่ที่ 1,000ms ฝั่งเก็บข้อมูลก็มองเห็นด้วยความละเอียดที่หยาบกว่า 100 เท่า และถ้าวัดกระบวนการที่มีรอบเวลา 30 วินาทีด้วยรอบ 1 วินาที ค่าคลาดเคลื่อนจะอยู่ที่สูงสุด ±1 วินาที คิดเป็นอัตรา 3.33%

ถ้าอยากเก็บการหยุดสั้น ๆ ให้ได้แน่นอน มีวิธีอยู่ 2 ทาง คือเพิ่มความถี่ของรอบการเก็บ หรือให้ฝั่ง PLC นับจำนวนครั้งและเวลาของการหยุด แล้วฝั่งเก็บข้อมูลเพียงอ่านค่าสะสมนั้น ทางหลังกลายเป็นการแก้แลดเดอร์ แต่แน่นอนกว่าเพราะหลุดพ้นจากข้อจำกัดของรอบเวลา ขอให้สื่อสารความต้องการที่ว่า “อยากเห็นการหยุดสั้น ๆ” ในฐานะข้อกำหนดเรื่องรอบการเก็บ ไม่ใช่ในฐานะเรื่องมาตรฐานการสื่อสาร ส่วนการนำการหยุดสั้น ๆ ที่เก็บได้ไปสะท้อนใน OEE อย่างไรนั้น เป็นการออกแบบอีกส่วนหนึ่งต่างหาก

สรุป

การเก็บข้อมูลจาก PLC ไม่ใช่ทางเลือกสองทางระหว่าง “เก็บได้” กับ “เก็บไม่ได้” สิ่งที่ถูกกำหนดไว้คือ จะผ่านเส้นทางใดใน 4 เส้นทาง ได้แก่ การอ่านตรงจาก PLC ที่มี Ethernet อยู่เดิม ฟังก์ชัน OPC UA Server การเพิ่มตัวแปลงสัญญาณอนุกรม และการติดจากภายนอกโดยไม่แตะ PLC เมื่อเส้นทางถูกกำหนดแล้ว ทั้งราคาต่อหน่วย ขอบเขตของตัวแปรที่เก็บได้ และสิ่งที่ต้องไปสอบถามผู้ผลิตเครื่องจักร ก็ถูกกำหนดตามไปด้วย เนื่องจากการมี 4 เส้นทางปะปนกันในโรงงานเดียวเป็นเรื่องปกติ ขอให้ตัดสินเป็นรายเครื่อง แทนที่จะถามว่า “โรงงานเราเก็บข้อมูลได้ไหม”

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

เราได้ประมาณการเรื่องค่าใช้จ่ายบนเงื่อนไขจำลองแล้ว แนวทาง A ที่จำกัดเฉพาะคอขวด 8 เครื่อง มีค่าใช้จ่ายเริ่มต้น 542,000 บาท ค่าใช้จ่ายรวม 5 ปี 992,000 บาท ผลประโยชน์สุทธิ 5 ปี +714,667 บาท และคืนทุนใน 2.16 ปี ส่วนแนวทาง B ที่ติดครบทั้ง 24 เครื่อง มีค่าใช้จ่ายเริ่มต้น 1,203,000 บาท ค่าใช้จ่ายรวม 5 ปี 1,818,000 บาท ผลประโยชน์สุทธิ 5 ปี −111,333 บาทซึ่งขาดทุน และคืนทุนใน 5.51 ปี ส่วนต่างคือ 826,000 บาท เนื่องจากมูลค่าผลที่ได้ของทั้งสองแนวทางเท่ากันที่ 1,706,667 บาท ส่วนต่างนี้จึงเป็นส่วนต่างของค่าใช้จ่ายตรง ๆ

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

ในขณะเดียวกัน ก็ไม่ได้แปลว่ายิ่งจำกัดขอบเขตยิ่งดี ในกรณีที่คอขวดมี 4 เครื่อง ค่าใช้จ่ายเริ่มต้น 390,000 บาทกลับให้ระยะเวลาคืนทุน 3.87 ปี ซึ่งช้ากว่า 2.16 ปีของกรณี 8 เครื่อง เพราะค่าใช้จ่ายคงที่อย่างเซิร์ฟเวอร์เก็บข้อมูลที่ 180,000 บาทยังคงอยู่ วิธีพูดที่แม่นยำคือ จำกัดขอบเขตลงมาถึงระดับที่ยังรวบรวมจำนวนครั้งได้มากพอจะเฉลี่ยค่าใช้จ่ายคงที่ให้บางลง

ถ้าสมมติฐานเปลี่ยน ข้อสรุปก็เปลี่ยน ถ้ากำไรที่สูญเสียต่อการหยุด 1 ชั่วโมงเปลี่ยนจาก 3,200 บาทเป็น 1,600 บาท ระยะเวลาคืนทุนของแนวทาง A ก็ยืดเป็น 6.72 ปีจนไม่คุ้มค่า และในกรณีที่ย่นเวลาได้เพียง 10 นาทีแทนที่จะเป็น 20 นาที ผลที่ได้ก็ลงเอยที่ 170,667 บาทต่อปีเท่ากัน ด้วยเหตุนี้เอง สิ่งที่ควรทำเป็นอันดับแรกจึงไม่ใช่การขอใบเสนอราคาจาก 3 เจ้า แต่คือ การรวมยอดบันทึกการหยุดเครื่องย้อนหลัง 12 เดือนเป็นรายเครื่อง แล้วแยกออกมาว่ารายการใดในนั้นที่นำไปสู่การลดลงของปริมาณการส่งมอบ ถ้ามีตารางเพียง 1 แผ่นนี้ การตัดสินว่าจะติดกับเครื่องใดก็เป็นเรื่องที่ทำได้แทบจะโดยอัตโนมัติ

ว่าจะผ่านเส้นทางใด และจะเลือกเครื่องจักรใดเป็นเป้าหมาย เป็นสิ่งที่ตัดสินไม่ได้หากยังไม่ได้ดูภายในตู้คอนโทรลและผลจริงของการหยุดเครื่อง TOMAS TECH มีฐานอยู่ที่กรุงเทพฯ และให้การสนับสนุนผู้ผลิตทุนญี่ปุ่นในด้าน Factory IT, OT/IoT และ FA ท่านสามารถปรึกษาเราได้ตั้งแต่ขั้นก่อนการเลือกรุ่น PLC และก่อนการขอใบเสนอราคา นั่นคือขั้นตอนการแยกทีละเครื่องว่า “เครื่องใดจะไปอยู่เส้นทางใด และตัวแปรที่ต้องการมีอยู่ในแลดเดอร์หรือไม่” นอกจากนี้ เรายังช่วยจัดระเบียบรายการที่ต้องสอบถามผู้ผลิตเครื่องจักร รวมถึงการสำรวจพื้นที่และแหล่งจ่ายไฟของตู้เดิม แล้วดำเนินการให้สอดคล้องกับสถานการณ์หน้างานของท่าน ปรึกษาเราได้ที่หน้าติดต่อเรา

ข้อมูลอ้างอิง

1. OPC Foundation “Field Level Communications Corner (มิถุนายน 2026)” สถานะความสมบูรณ์ของ C2C และการเตรียมส่วนขยาย C2D ของ OPC UA FX พร้อมงาน IOP และความเคลื่อนไหวสู่ SPS 2026

https://opcconnect.opcfoundation.org/2026/06/field-level-communications-corner-june-2026/

1. EMQ “A Comparison of IIoT Protocols — MQTT Sparkplug vs OPC UA” และ HiveMQ “IIoT Protocols — OPC UA, MQTT, Sparkplug Comparison” เรื่อง topic namespace เพย์โหลดที่มีชนิดข้อมูลกำกับ ใบรับรอง birth/death ของ Sparkplug และการแบ่งบทบาทกับ OPC UA

https://www.emqx.com/en/blog/a-comparison-of-iiot-protocols-mqtt-sparkplug-vs-opc-ua และ https://www.hivemq.com/resources/iiot-protocols-opc-ua-mqtt-sparkplug-comparison/

1. Trout Software “Real-time PLC Data Streaming — OPC UA, Modbus and Modern Integration Patterns” เรื่องการโพลลิ่งกับการอ่านเป็นบล็อกของ Modbus เพดานความเร็วของสัญญาณอนุกรม และ subscription ของ OPC UA

https://www.trout.software/blog/real-time-plc-data-streaming-opc-ua-modbus-and-modern-integration-patterns

1. Xinhua (27 กรกฎาคม 2026) ดัชนีผลผลิตอุตสาหกรรมไทย (MPI) เดือนมิถุนายน 2026 อยู่ที่ −3.10% ไตรมาสที่ 2 อยู่ที่ −1.79% และอัตราการใช้กำลังการผลิตเฉลี่ย 57.47% โดยมีที่มาจากสำนักงานเศรษฐกิจอุตสาหกรรม กระทรวงอุตสาหกรรม

https://english.news.cn/20260727/f8b7ceb202d04b1f8facbcbf44ed60ce/c.html

1. Mahanakorn Partners Group “Thailand Approves New Tax Incentive to Accelerate SME Digital Transformation” เรื่องผู้มีสิทธิ เพดาน 300,000 บาท เงื่อนไขการขึ้นทะเบียนกับ depa และกำหนดสิ้นสุด 31 ธันวาคม 2027 ของมาตรการหักรายจ่าย 200%

https://mahanakornpartners.com/thailand-approves-new-tax-incentive-to-accelerate-sme-digital-transformation/

1. JETRO Business Short News (กรกฎาคม 2025) ค่าจ้างขั้นต่ำของไทยในกรุงเทพมหานครและเขตอุตสาหกรรมอยู่ที่วันละ 400 บาท

https://www.jetro.go.jp/biznews/2025/07/b21007a1ac8f7fca.html

1. World Bank “Thailand Economic Monitor February 2026 — Advanced Green Manufacturing for Growth”

https://www.worldbank.org/en/country/thailand/publication/thailand-economic-monitor-february-2026-advanced-green-manufacturing-for-growth

1. สำนักงานเศรษฐกิจอุตสาหกรรม (OIE) Industrial Indices แหล่งเผยแพร่ปฐมภูมิของ MPI

https://www.oie.go.th/view/1/industrial_indices/EN-US