โรงงานอุตสาหกรรมส่วนใหญ่ในปัจจุบันยังคงถูกขับเคลื่อนด้วยระบบ Monolithic — ซอฟต์แวร์ MES, SCADA และ ERP ที่ใหญ่โต ผูกกันแน่น และยากต่อการเปลี่ยนแปลง เมื่อต้องการเพิ่มฟังก์ชันใหม่หรือเปลี่ยนผู้ขาย มักต้อง “รื้อทั้งบล็อก” ซึ่งใช้เวลาและความเสี่ยงสูง แนวคิด Composable Manufacturing ที่ต่อยอดจาก Gartner Composable Enterprise นำเสนอวิธีคิดใหม่: แยกระบบออกเป็น บล็อกย่อยที่ประกอบกันได้ เหมือน LEGO ผสานกับ IIoT และ Microservices เพื่อสร้างโรงงานดิจิทัลที่ยืดหยุ่น ขยายได้ และเปลี่ยนชิ้นส่วนได้โดยไม่กระทบทั้งระบบ
Composable Manufacturing คืออะไร?
Composable Manufacturing เป็นแนวทางสถาปัตยกรรมที่มองระบบการผลิตเป็นชุดของ Packaged Business Capabilities (PBCs) แต่ละ PBC เป็นโมดูลซอฟต์แวร์อิสระที่ทำหน้าที่เฉพาะ เช่น การจัดตารางผลิต การติดตาม OEE หรือการจัดการคลังวัตถุดิบ แต่ละโมดูลมี API ของตัวเอง สื่อสารผ่าน Event Bus และสามารถถูกประกอบ เปลี่ยน หรือถอดออกได้โดยไม่กระทบโมดูลอื่น Gartner ระบุหลักการ 4 ข้อที่เรียกว่า MODA
- M — Modularity: แบ่งระบบเป็นโมดูลย่อยที่มีหน้าที่ชัดเจนและขอบเขตแน่น (Bounded Context)
- O — Orchestration: ประสานโมดูลผ่าน Workflow Engine หรือ Choreography แบบ Event-Driven
- D — Discovery: โมดูลลงทะเบียนตัวเองและค้นพบกันได้อัตโนมัติผ่าน Service Registry
- A — Autonomy: แต่ละโมดูลตัดสินใจได้ในขอบเขตของตน ไม่ต้องรอคำสั่งจากระบบกลางแบบ Top-Down
Monolithic vs Microservices vs Composable: ตารางเปรียบเทียบ
| มิติเปรียบเทียบ | Monolithic (ดั้งเดิม) | Microservices | Composable |
|---|---|---|---|
| ขนาด Deployment Unit | 1 ชิ้นใหญ่ | หลายชิ้นเล็ก | PBC + UI Block |
| การเปลี่ยนผู้ขาย | ยากมาก | ปานกลาง | ง่าย (Vendor-Agnostic) |
| การเพิ่มฟังก์ชันใหม่ | เดือน–ปี | สัปดาห์ | วัน–สัปดาห์ |
| การปรับแต่ง UI | หน้าจอตายตัว | แยก Frontend | No-Code Assembly |
| ความสัมพันธ์กับ IIoT | แบบ Point-to-Point | API Gateway | Event-Driven Native |
สถาปัตยกรรม Composable Manufacturing ในโรงงานจริง
สถาปัตยกรรมแบบ Composable มักประกอบด้วย 4 Layer ที่สื่อสารกันผ่าน Event Streaming และ API มากกว่าการเรียกฟังก์ชันตรงแบบเดิม
- IIoT Edge Layer: เซ็นเซอร์และ PLC ส่งข้อมูลผ่าน OPC UA, MQTT Sparkplug B ไปยัง Edge Gateway ที่ทำ Protocol Translation และ Edge Analytics เช่น การคำนวณ OEE แบบ Real-Time
- Event Backbone: Apache Kafka หรือ Message Broker ทำหน้าที่เป็น “เส้นเลือด” ที่ทุก PBC ส่งและรับ Event แบบ Asynchronous ทำให้ระบบทนต่อการล่มของโมดูลใดโมดูลหนึ่ง
- PBC Layer (Business Capabilities): แต่ละ PBC ทำงานใน Container (Docker) และถูกจัดการด้วย Kubernetes ตัวอย่าง PBC ในโรงงาน เช่น Production Scheduling, Quality Inspection, Energy Monitoring, Asset Health, Traceability
- Composition & Experience Layer: No-Code/Low-Code Platform ให้ผู้ใช้ปลายทางลากวาง PBC และ Widget สร้าง Dashboard หรือ Application ตามความต้องการ โดยไม่ต้องเขียนโค้ด
ตัวอย่าง PBC ในโรงงานอุตสาหกรรม
การออกแบบ PBC ที่ดีต้องสอดคล้องกับ ISA-95 ที่แบ่งระบบการผลิตเป็นระดับ hierarchy แต่ละ PBC ควรจับความสามารถทางธุรกิจหนึ่งอย่างและเปิด API ที่ชัดเจน
- Production Execution PBC: รับ Work Order, สั่งการ PLC, บันทึก Cycle Time และ Yield ส่งผ่าน OPC UA
- Quality Management PBC: รับภาพจาก Vision System, ตัดสินใจผ่าน AI Model, ส่งผล Defect Rate กลับเข้า Event Bus
- Energy Monitoring PBC: รวบรวม Power Meter Reading ทุก 15 นาที, คำนวณ Energy Intensity (kWh/หน่วยผลผลิต), แจ้งเตือนเมื่อเกิน Baseline
- Predictive Maintenance PBC: รับ Vibration & Temperature Data, พยากรณ์ Remaining Useful Life (RUL) ด้วย Machine Learning
- Traceability PBC: บันทึก Genealogy ของแต่ละ Batch ตามมาตรฐาน GS1, สร้าง Digital Thread ตลอด Supply Chain
IIoT คือตัวเชื่อมที่ทำให้ Composable เป็นไปได้
สถาปัตยกรรมแบบ Composable อาศัย Decoupling ระหว่างระบบเป็นหลัก แต่ถ้าอุปกรณ์บนพื้นโรงงานยังติดต่อแบบ Point-to-Point กับซอฟต์แวร์เฉพาะ การแยกส่วนจะเป็นไปไม่ได้ IIoT ทำหน้าที่เป็น Abstraction Layer ที่ทำให้ทุก PBC เข้าถึงข้อมูลเครื่องจักรได้ผ่านทางเดียวกัน คือ Event Bus โดยไม่สนว่าเครื่องจักรนั้นใช้ Modbus, EtherCAT หรือ Proprietary Protocol
[ตัวอย่าง Use Case] โรงงานอุปกรณ์อิเล็กทรอนิกส์ต้องการเพิ่มฟังก์ชันพยากรณ์อุณหภูมิ Mold ในเครื่องฉีดพลาสติก ในสถาปัตยกรรม Monolithic ต้องแก้ซอฟต์แวร์ SCADA, ทดสอบใหม่ทั้งระบบ และ Deploy ช่วงหยุดโรงงาน ใน Composable Architecture ทีมเพียง Deploy Predictive Maintenance PBC ใหม่ใน Container, สมัครรับ Event อุณหภูมิจาก Event Bus แล้วเปิดบริการผ่าน API — โดยไม่ต้องหยุดไลน์ผลิตเลย
ประโยชน์ที่จับต้องได้
- Time-to-Market เร็วขึ้น: การเพิ่มฟังก์ชันใหม่จากเดือนลดเหลือวัน–สัปดาห์ เพราะ PBC พัฒนา ทดสอบ และ Deploy แยกจากกันอย่างอิสระ
- Vendor Lock-in ลดลง: ถ้า PBC หนึ่งไม่ตอบโจทย์ สามารถเปลี่ยนเป็นของผู้ขายอื่นที่เปิด API ตรงตามข้อกำหนดได้ โดยระบบอื่นไม่ได้รับผลกระทบ
- Scalability แบบ Selective: ถ้าโมดูล Vision Inspection ต้องการพลังประมวลผลสูงในวันตรวจสอบ LOT ใหญ่ สามารถ Scale แค่โมดูลนั้นใน Kubernetes ได้ ไม่ต้องอัปเกรดเซิร์ฟเวอร์ทั้งตัว
- Resilience สูง: เมื่อ PBC หนึ่งล่ม ระบบอื่นยังทำงานต่อได้เพราะสื่อสารแบบ Asynchronous ผ่าน Event Bus ที่เก็บ Message ไว้รอ
ความท้าทายในการนำไปใช้
Composable Manufacturing ไม่ใช่สิ่งที่สร้างได้ในคืนเดียว ความท้าทายหลักคือ การกำหนดขอบเขตของแต่ละ PBC ให้ถูกต้อง (Domain-Driven Design) ถ้าแบ่งเล็กไปจะมี Overhead ในการสื่อสารสูง ถ้าแบ่งใหญ่ไปจะกลายเป็น Mini-Monolith นอกจากนี้ทีม IT/OT ต้องเรียนรู้ทักษะใหม่ เช่น Container Orchestration, API Design, Event Sourcing และ Observability (การติดตามสถานะระบบกระจาย) ซึ่งต่างจากการดูแล SCADA แบบดั้งเดิมอย่างสิ้นเชิง
Key Takeaways
- Composable Manufacturing แบ่งระบบการผลิตเป็น Packaged Business Capabilities (PBCs) ที่ประกอบกันได้แบบ LEGO ตามหลัก MODA: Modularity, Orchestration, Discovery, Autonomy
- แตกต่างจาก Monolithic ตรงที่เปลี่ยนผู้ขายและเพิ่มฟังก์ชันได้ง่าย เพราะ PBC แต่ละตัวอิสระและสื่อสารผ่าน API/Event Bus
- สถาปัตยกรรม 4 Layer: IIoT Edge (OPC UA/MQTT) → Event Backbone (Kafka) → PBC Layer (Kubernetes Container) → Composition Layer (No-Code Dashboard)
- ตัวอย่าง PBC ในโรงงาน: Production Execution, Quality Management, Energy Monitoring, Predictive Maintenance, Traceability — สอดคล้องกับ ISA-95
- IIoT ทำหน้าที่เป็น Abstraction Layer ที่ทำให้ทุก PBC เข้าถึงข้อมูลเครื่องจักรผ่าน Event Bus ได้ทางเดียวกัน ไม่สน Protocol ดั้งเดิม
- ประโยชน์วัดได้ 4 ด้าน: Time-to-Market เร็วขึ้น, Vendor Lock-in ลดลง, Scalability แบบ Selective, และ Resilience สูงจากการสื่อสารแบบ Asynchronous
- ความท้าทายหลักคือการกำหนดขอบเขต PBC ด้วย Domain-Driven Design และการยกระดับทักษะทีม IT/OT สู่ Container, API และ Observability
ที่มาภาพประกอบ: Factory Automation Robotics — Public Domain ผ่าน Wikimedia Commons