How-to: รวม Digital Twin หลายตัวให้คุยกันได้ — Federated Twin ตาม ISO 23247-6 ใน 6 ขั้นตอน

โรงงานที่ทำ Digital Twin มาสักพักมักเจอภาพนี้: ฝ่ายผลิตมี Twin ของเครื่องจักร, ฝ่ายคลังมี Twin ของระบบวางแผนสินค้าคงคลัง, ฝ่ายซ่อมบำรุงมี Twin อีกตัว — ทุกตัวเก่งในโลกของตัวเอง แต่ไม่มีตัวไหนตอบได้ว่า “ถ้าเครื่อง CNC 2 ตัวลงพร้อมกันพรุ่งนี้ ใบสั่งผลิตชุดไหนจะช้ากว่ากำหนด” คำตอบของปัญหานี้คือ Federated Digital Twin — การประกอบ Twin หลายตัวเข้าด้วยกันโดยไม่ต้องรื้อทุกอย่างมาสร้างใหม่

มาตรฐานที่ต้องรู้: ISO 23247-6

ส่วนที่ 6 ของมาตรฐาน ISO 23247 (Digital twin framework for manufacturing) นิยามกระบวนการ Digital Twin Composition (DTC) — การรวม Twin หลายตัวเป็น Twin ที่ซับซ้อนกว่า โดยแบ่งเป็น 2 แนวทางหลัก:

• Integrated DTC — รวมเป็น Twin เดียวแบบรวมศูนย์ มี entity กลางคอยจัดการการแลกเปลี่ยนข้อมูล
• Federated DTC — Twin แต่ละตัวโต้ตอบกันแบบ peer-to-peer โดยไม่มีศูนย์กลางควบคุม แต่ละตัวขอ-ให้บริการและข้อมูลซึ่งกันและกันได้โดยตรง ยังรักษาฟอร์แมตของตัวเองไว้ และมี control logic กระจายอยู่ทั้งเครือข่าย

แนวตั้งหรือแนวนอน — เลือกให้ถูกโครงสร้าง

งานวิจัยจาก University of Antwerp ปี 2025 แบ่งสถาปัตยกรรมการรวม Twin เป็น 2 รูปแบบ ซึ่งเลือกต่างกันตามโครงสร้างอำนาจในองค์กร:

6 ขั้นตอนสร้าง Federated Twin

1. ทำ Inventory ของ Twin ที่มี — สำรวจว่าแต่ละฝ่ายมี Twin อะไร ใช้โปรโตคอลอะไร (OPC UA, MQTT, REST API), ใครเป็นเจ้าของ และ update ความถี่เท่าไร งานวิจัยด้าน automotive ชี้ว่าปัญหาหลักคือ “fragmentation” — Twin ถูกสร้างแยกตามเฟสของวงจรชีวิตผลิตภัณฑ์จนคุยกันไม่ได้
2. เลือกแบบแผน (Vertical/Horizontal/Hybrid) — ถ้าเป็นโรงงานเดียวมีสายบังคับ เริ่มจาก Vertical ถ้ามีหลายเจ้าของ เช่น โรงงานกับคู่ค้า ใช้ Horizontal คนละกรณีใช้ Hybrid ผสมกันได้
3. สร้าง Federation Layer ทำ semantic mapping — หัวใจของงานนี้คือทำให้ “ชิ้นงาน” ของ Twin A หมายถึงสิ่งเดียวกับ “lot” ของ Twin B ใช้ Companion Specification ของ OPC UA หรือแนวคิด Asset Administration Shell เป็นตัวแปลภาษากลาง โดยทั่วไป mapping 1 ตัวแปรใช้เวลา 15-30 นาทีในการนิยามและทดสอบ แต่ต่างจากการรวมข้อมูลแบบ monolithic ตรงที่ทำครั้งเดียวใช้ได้กับทุก Twin ที่พูดภาษากลางเดียวกัน
4. วาง Event Bus + กติกาการแลกเปลี่ยน — Twin แต่ละตัวไม่ต้องสตรีมข้อมูลตลอดเวลา แต่ประกาศ “เหตุการณ์” ที่คนอื่นสนใจ เช่น เครื่องจักรเปลี่ยนสถานะเป็น downtime แล้ว Twin คลังจะได้ปรับแผนจัดส่งทันที กติกาที่ใช้ได้จริง: telemetry ระดับเครื่องใช้ MQTT QoS 1 ทุก 100-500 ms เฉพาะตัวแปรที่เปลี่ยน (deadband filtering), เหตุการณ์สถานะสำคัญ publish ทันทีไม่เกิน 1 วินาที และ snapshot ประจำทั้งระบบทุก 5 นาทีเพื่อให้ Twin ที่เพิ่งเข้าร่วม catch up ได้
5. กำหนดสิทธิ์และความเป็นส่วนตัว — คนละฝ่ายคนละเจ้าของ ต้องกำหนดว่าข้อมูลไหนแชร์ได้ ข้อมูลไหนเป็น internal งานวิจัยด้าน federated learning ช่วยได้: แชร์ “โมเดล” แทน “ข้อมูลดิบ” ในกรณีที่อ่อนไหว
6. ทดสอบ Interoperability จริง — สร้าง scenario ที่ต้องใช้ข้อมูลข้าม Twin เช่น trace defect ย้อนกลับจากลูกค้าถึงเครื่องจักรตัวที่ผลิตชิ้นงานนั้น แล้ววัดเวลาตอบสนองของทั้งระบบ

ตัวอย่างจริงจากงานวิจัย Automotive

งานวิจัยปี 2026 ของบริษัทยานยนต์รายใหญ่สร้าง FDT system รวม Twin ที่กระจัดกระจายตามเฟสวงจรชีวิตรถยนต์ — ออกแบบ, ผลิต, ใช้งาน, บำรุง — โดยไม่รื้อแพลตฟอร์มเดิม แต่เพิ่มชั้น federation เข้าไป ผลคือลดความซับซ้อนของการเชื่อมต่อ และตอบสนอง scenario สำคัญได้เร็วขึ้น เช่น การ trace ตำหนิย้อนกลับข้ามเฟส ที่เดิมต้องรวบรวมข้อมูลจากหลายระบบเอง

ข้อผิดพลาดที่พบบ่อย

• สร้าง Twin กลางตัวใหม่แบบ monolithic — เป็นสิ่งที่ federation พยายามหลีกเลี่ยง ถ้าต้องรวมทุกอย่างเป็นไฟล์เดียว แปลว่ายังไม่เข้าใจปัญหา
• ลืมว่า Twin แต่ละตัวมีเจ้าของ — การดึงข้อมูลจาก Twin ของฝ่ายอื่นต้องผ่านข้อตกลง ไม่ใช่ดึงได้เลยเพราะอยู่ในเครือข่ายเดียวกัน
• ไม่กำหนดเวอร์ชันของ semantic model — เมื่อ Twin ตัวหนึ่งอัปเดตโครงสร้างข้อมูล ตัวอื่นที่ยังใช้ตารางเก่าจะแปลผิดเงียบๆ ต้องมี versioning ชัดเจน

ทีม System Integration ของ Honey Corporation มีประสบการณ์เชื่อมระบบควบคุมเครื่องจักรหลากหลายโปรโตคอลให้กลายเป็นข้อมูลที่ใช้ตัดสินใจร่วมกันได้ — หัวใจเดียวกับการทำ federation คือทำให้ทุกฝ่ายเข้าใจภาษากลางโดยไม่ต้องเสียอธิปไตยเหนือข้อมูลของตัวเอง

Key Takeaways

1. Federated DTC ตาม ISO 23247-6 คือการรวม Twin หลายตัวแบบ peer-to-peer โดยไม่มีศูนย์กลางควบคุม — ต่างจาก Integrated DTC ที่ต้องมี entity กลาง
2. Vertical Federation เหมาะกับโครงสร้างลำดับชั้น ISA-95 ในโรงงานเดียว, Horizontal Federation เหมาะกับหลายเจ้าของ เช่น supply chain ข้ามบริษัท
3. Semantic mapping ผ่าน Companion Specification หรือ Asset Administration Shell คือหัวใจ — ทำให้ “ชิ้นงาน” ของ Twin A และ “lot” ของ Twin B หมายถึงสิ่งเดียวกัน
4. แลกเหตุการณ์ ไม่ใช่แลกข้อมูลตลอดเวลา — Twin ที่ดีประกาศเหตุการณ์สำคัญ (เช่น เปลี่ยนสถานะ downtime) ให้ผู้อื่นตอบสนอง แทนการสตรีมข้อมูลดิบทั้งหมด
5. ต้องมี versioning ของ semantic model — Twin ที่อัปเดตโครงสร้างข้อมูลโดยไม่แจ้งตัวอื่น ทำให้ระบบแปลผิดเงียบๆ จนเสียหาย
6. อย่ารื้อแพลตฟอร์มเดิม — งานวิจัย automotive ปี 2026 พิสูจน์ว่าเพิ่มชั้น federation บน Twin ที่กระจัดกระจายก็ได้ผล โดยลดความซับซ้อนของการเชื่อมต่อ