How-to: สร้าง Digital Twin ของระบบควบคุมเครื่องจักรเก่า — ถอด Logic สู่ Behavioral Twin ใน 6 ขั้นตอน

โรงงานที่มีเครื่องจักรอายุ 10–20 ปีกำลังเจอปัญหาเดียวกัน: ระบบควบคุมเก่า อะไหล่หายาก และไม่มีใครกล้าแตะ Logic ที่เขียนไว้สมัยคนละยุค — เพราะแก้แล้วไลน์อาจหยุดทั้งวัน บทความนี้คือคู่มือทีละขั้น การสร้าง Digital Twin ของระบบควบคุมเครื่องจักรเก่า เพื่อทดสอบทุกอย่างในโลกเสมือนก่อนแตะโลกจริง แม้เครื่องจักรตัวนั้นจะอายุ 15 ปีแล้วก็ตาม

ทำไมต้องเป็น Twin ของ “ระบบควบคุม” ไม่ใช่แค่หน้าตาเครื่องจักร

Digital Twin ของเครื่องจักรเก่ามี 2 ระดับ ระดับแรกคือ 3D Model ที่สวยงามเหมาะกับการนำเสนอ ระดับที่สองคือ Behavioral Twin ที่จำลองพฤติกรรมการควบคุมจริง: Logic การทำงาน, Sequence การเริ่มเครื่อง, Interlock, และการตอบสนองต่อคำสั่ง ระดับที่สองนี่แหละที่มีคุณค่าทางวิศวกรรม เพราะมันทำให้คุณทดลองแก้ Logic, ทดสอบ Patch ใหม่ และฝึกคน โดยไม่เสี่ยงหยุดไลน์ผลิตจริง

ภาพรวมก่อนเริ่ม: สิ่งที่ต้องมี

*ระยะเวลาขึ้นกับความซับซ้อนของเครื่องจักรและความสมบูรณ์ของเอกสารเดิม

ขั้นที่ 1: ถอด Logic เดิมออกจากเครื่องจักร (Logic Extraction)

เริ่มจากดึงโปรแกรมควบคุม (Ladder Diagram, Function Block) ออกจาก PLC เดิมให้ได้มากที่สุด ปัญหาคือหลายโรงงานสูญเสีย Source Code ต้นฉบับ เหลือแค่ไฟล์ Compile แล้ว หรือระบบเก่าจน Software สำหรับเปิดไม่รองรับ OS ปัจจุบัน แนวทางที่ใช้ได้จริง:

• Reverse Engineering แบบมีจรรยาบรรณ — ใช้ Documentation ที่หลงเหลือ (P&ID, Wiring Diagram, O&M Manual) ผสมกับการสังเกตพฤติกรรมจริงตอนเครื่องทำงาน สร้างเป็น State Diagram ของแต่ละ Sequence
• บันทึกสัญญาณ I/O จริง — ต่อ Data Logger เก็บสถานะ Input/Output ของ PLC ต่อเนื่องอย่างน้อย 2–4 สัปดาห์ ครอบคลุมทุกโหมดการทำงาน (Start-up, Normal, Stop, Alarm) ข้อมูลชุดนี้จะเป็น “ครูผู้สอน” ให้โมเดลในขั้นถัดไป
• สัมภาษณ์ผู้เชี่ยวชาญ (Expert Elicitation) — ช่างเต็มเวลาที่ดูแลเครื่อง 15 ปี มีความรู้ที่ไม่เคยถูกเขียนลงเอกสาร จดทุก “ถ้า…แล้วต้อง…” ที่เขาเล่า นั่นคือ Tacit Knowledge ที่ล้ำค่าที่สุดและหายไปเมื่อเขาเกษียณ

ขั้นที่ 2: สร้าง Behavioral Model จากข้อมูลที่ได้

เลือกเทคนิคตามลักษณะของระบบ: ระบบที่มี Logic ชัดเจน (Sequence การทำงานเป็น Step) เหมาะกับ Finite State Machine (FSM) ส่วนระบบที่พฤติกรรมซับซ้อน ผสมกันหลายตัวแปร เหมาะกับโมเดล Machine Learning ที่เรียนรู้จากข้อมูล I/O ที่บันทึกไว้ในขั้นที่ 1

เคล็ดลับสำคัญ: อย่าหวังสร้าง Twin ที่เหมือนจริง 100% ในครั้งแรก เริ่มจากครอบคลุมพฤติกรรมหลัก 80% ที่ใช้บ่อยที่สุด (Normal Operation) แล้วค่อยเพิ่มเติม Edge Case ทีหลัง โมเดลที่ “พอใช้แต่ถูกต้อง” มีค่ากว่าโมเดลที่ “สมบูรณ์แต่ไม่มีวันเสร็จ”

ขั้นที่ 3: เชื่อมข้อมูลจริงด้วย Soft Sensor และเกตเวย์ IIoT

เครื่องจักรเก่ามักไม่มี Sensor ดิจิทัล แต่เกือบทุกตัวมีสัญญาณ 4–20mA หรือ Contact ที่สามารถต่อเพิ่มได้ ทางเลือกคือติด IIoT Gateway ที่อ่านค่าจากจุดเหล่านี้ผ่านโปรโตคอลอุตสาหกรรม เช่น Modbus RTU แล้วส่งขึ้น Twin ผ่าน MQTT สำหรับค่าที่วัดโดยตรงไม่ได้ เช่น อุณหภูมิภายในบรรจุภัณฑ์ฉนวน ใช้เทคนิค Soft Sensor — คำนวณจากค่าอื่นที่วัดได้ เช่น ใช้กระแสมอเตอร์กับความเร็วรอบประมาณความร้อนสะสม

ขั้นที่ 4: Validate โมเดล — จุดตัดใจที่หลายคนข้าม

วิธีที่เป็นรูปธรรม: เทียบ Output ของ Twin กับสัญญาณจริงที่บันทึกไว้ โดยเลือกช่วงเวลาที่เครื่องจักรทำงานหลากหลายโหมด ตั้งเกณฑ์ความคลาดเคลื่อนที่ยอมรับได้ล่วงหน้า เช่น สถานะ Digital ต้องตรงกัน 100% และค่า Analog คลาดเคลื่อนไม่เกิน 5% ถ้าไม่ผ่าน ให้กลับไปเก็บข้อมูลเพิ่มในจุดที่โมเดลพลาด แล้วเทรนซ้ำ — กระบวนการนี้เป็นวงจร ไม่ใช่เส้นตรง

ขั้นที่ 5: ทดลองแก้ Logic อย่างอิสระ

เมื่อ Twin ผ่านการ Validate แล้ว ทุกการแก้ไข Logic ของเครื่องจักรเก่าให้ทดสอบบน Twin ก่อนเสมอ: รัน Simulation กับข้อมูลจริงย้อนหลัง (Replay) เพื่อดูว่า Logic ใหม่ตอบสนองต่างจากเดิมอย่างไร จับกรณีที่ Interlock ควรทำงานแต่ไม่ทำ และทดสอบ Boundary Case เช่น เซ็นเซอร์เสียกลาง Sequence แล้วระบบควร Recovery อย่างไร

ขั้นที่ 6: Deploy พร้อมระบบ Rollback + ใช้ Twin เป็นห้องฝึก

ตอน Deploy จริง ให้เตรียมแผนกลับสู่ Logic เดิม (Rollback) เสมอ และหลัง Deploy ให้เทียบพฤติกรรมจริงกับที่ Twin ทำนายไว้ต่ออีก 1–2 สัปดาห์ ส่วน Twin ไม่ได้หมดบทบาทหลังจากนั้น — มันกลายเป็น ห้องฝึกอบรม (Training Simulator) ให้พนักงานใหม่ ลดเวลา Onboarding ที่เคยต้องพึ่งพาช่างเก่า และเป็นเอกสารมีชีวิตที่อัปเดตทุกครั้งที่ Logic เปลี่ยน

ประสบการณ์จากงานจริง: ทีม Honey Corporation เคยทำโปรเจกต์ Retrofit ระบบควบคุมในโรงงานอาหารและระบบทำความเย็น ที่ต้องถอด Logic จากอุปกรณ์เก่าและเชื่อมข้อมูลขึ้น IIoT Platform บทเรียนที่ชัดที่สุดคือ “เอกสารไม่เคยตรงกับของจริง 100%” — การมี Twin ช่วยให้เราพิสูจน์สมมติฐานทุกขั้นตอนก่อนแตะเครื่องจักรจริง ลดความเสี่ยงการหยุดไลน์ที่ไม่จำเป็นอย่างมาก

Key Takeaways

1. เครื่องจักรเก่าไม่ใช่ข้อจำกัดของ Digital Twin — แต่เป็นกลุ่มที่ได้ประโยชน์มากที่สุด เพราะความรู้กำลังหายไปพร้อมคนเก่า
2. Logic Extraction คือขั้นที่ยากที่สุด — ลงแรงตรงนี้ให้มาก ใช้ทั้งเอกสาร ข้อมูล I/O จริง และความรู้ของช่างเต็มเวลา
3. เริ่มที่ 80/20 — ครอบคลุมพฤติกรรมหลักก่อน อย่าหลงมัวไปกับความสมบูรณ์แบบของโมเดล
4. Validation ต้องตั้งเกณฑ์ล่วงหน้า — Digital 100% ตรง, Analog คลาดเคลื่อนไม่เกิน 5% แล้วยอมรับผลตามเกณฑ์นั้น
5. Twin ที่ดีมีชีวิตยืนยาวกว่าโปรเจกต์ — ใช้เป็น Training Simulator, เอกสารมีชีวิต และสนามทดสอบ Patch ถัดไป
6. แผน Rollback บังคับ — การทดสอบบน Twin ลดความเสี่ยง แต่ไม่ได้แปลว่าโอกาสพลาดเป็นศูนย์