03.1 Using Tulip as an APS
1. Data Model—สร้าง Tulip Tables ให้เทียบเท่า APS
| Table Group | Columns (ตัวอย่าง) | จุดประสงค์ |
|---|---|---|
| master_data | customer_code, product_code, workstation_id | ขอบเขตการผลิต (Customer/Product/Machine) |
| routing | product_code, step_no, workstage_id, std_setup_min, std_run_min | BOM + Routing สำหรับสร้าง Jobs |
| orders | order_no, customer, qty, due_date | Demand ที่ดึงจาก ERP |
| capacity_calendar | workstation_id, date, shift, avail_min, efficiency_pct | กำหนดกำลังผลิตตามกะ |
| jobs_plan | job_id, order_no, step_no, planned_start, planned_end, workstation_id | กำหนดเวลาใน Gantt |
| inventory | material_code, free_qty | ตรวจ material constraint |
| timelogs | job_id, start_actual, end_actual, qty_good, machine_state | Feedback จาก Shop-floor |
| sync_log | ext_system, payload, status, timestamp | Audit / Traceability |
ใช้ Table API เพื่อ “upsert” จากระบบนอก (ERP, WMS) อย่าง idempotent
2. Connectivity—ดึง–ส่งข้อมูลแบบ Real-time
HTTP/REST Connectors → ดึง Master Data & Work Orders จาก ERP/MES ตามแนวทางการบูรณาการของ Tulip
SQL Connectors → อ่าน Work Center Load จาก Data Warehouse ถ้ามี
OPC-UA / Edge MC → สตรีม Machine State & Cycle Time ไปยัง Table timelogs
Table API Outbound → ส่งผล Schedule กลับ ERP เพื่อ MRP-II / ShopFloor Control
3. Scheduling Engine—สองทางเลือก
A. No-Code Trigger Scheduling (เหมาะ Pilot / Low-Mix)
ใช้ Timer Trigger คำนวณ Forward / Backward pass แล้วเขียนผลลง jobs_plan
Expression Editor ช่วยหา max(planned_end) ของ step ก่อนหน้าเป็น earliest_start ใหม่
B. External Optimizer (High-Mix / Constraint-Based)
สร้าง Micro-service (Python OR-Tools หรือ OptaPlanner) บนอุปกรณ์ Edge หรือ AWS Lambda
เรียกผ่าน HTTP Connector ฟังก์ชัน /solveSchedule รับ JSON Master+Demand → คืน JSON Jobs
Triggers รับ JSON ผลลัพธ์แล้ว Bulk Upsert jobs_plan ด้วย Table API
ใช้ Dynamic Priority หรือ Rule Table ปรับ weight / objective ต่าง ๆ
ในที่นี้ Scheduling Engine คือโมดูลที่
รับ orders + routing + resources capacity เป็นอินพุต
ใช้ algorithm คำนวณตารางเวลาอยู่บน constraint จริง (finite capacity, precedence, due-date)
คืน planned_start/end + resource assignment ออกไปให้ UI/MES
🟢 High-Priority / Must-Have (สร้างใน MVP)
| # | Feature (English keyword) | เหตุผล & อ้างอิง |
|---|---|---|
| 1 | Finite Capacity Scheduling | ทำให้แผน “realistic” โดยคำนึงกำลังเครื่อง/คน ซึ่งเป็น core ของทุก APS software (Software Connect) |
| 2 | Precedence / Dependency Handling (Finish-to-Start) | ควบคุม flow ตาม routing; เป็น constraint หลักใน Job-Shop models (ScienceDirect) |
| 3 | Single Objective – Minimize Total Tardiness (หรือ FIFO tie-break) | ลด late order ได้มากในต้นทุน compute ต่ำ (ScienceDirect) |
| 4 | Basic Heuristic Solver (เช่น Forward/Backward pass หรือ CP-SAT demo of OR-Tools) | พัฒนาเร็วและ Google OR-Tools มีตัวอย่าง Job-Shop ให้ดัดแปลงทันที (Google for Developers) |
| 5 | Incremental / Partial Reschedule | เมื่อเครื่องล่มให้ “ขยับเฉพาะงานที่เหลือ” ลด runtime และความชุลมุน (SpringerLink) |
| 6 | Frozen Zone / Time-Fence | ป้องกัน Engine เปลี่ยนงานที่กำลังผลิตภายใน X ชั่วโมงข้างหน้า (ERP Information) |
| 7 | Explain Critical Path & Delay Cause | ให้ Planner เห็น ทำไม job หลุดกำหนด (audit friendly) (VERTEX) |
| 8 | Make-span KPI Export | แม้ใช้ tardiness objective ควรคำนวณ make-span ไว้เทียบ (Chalmers Publication Library (CPL)) |
| 9 | Configurable Solve Time-box (e.g. 30 sec) | Industry 4.0 ต้องตอบสนองเกือบ real-time; time-boxed searchเป็นแนวปฏิบัติทั่วไป (Siemens Blog Network) |
| 10 | Basic Logging / Audit Trail ของ input-output JSON | รองรับมาตรฐานคุณภาพ (ISO/FDA); เก็บเพื่อ debug & compliance (ScienceDirect) |
⏱️ ผลลัพธ์ MVP: ได้แผน finite-capacity, ลดงานสาย, ปรับหลังเครื่องล่มได้ภายในวินาที ไม่ต้องสร้าง meta-heuristic ซับซ้อน
🟡 Low-Priority / Phase-2-3 (ทำภายหลัง)
| Feature | เหตุผลเลื่อน | อ้างอิง |
|---|---|---|
| Sequence-Dependent Setup Time | ต้องเพิ่ม matrix ระหว่างงาน → algorithm ซับซ้อนขึ้น (ScienceDirect) | |
| Multi-Resource Coupling / Skill Matrix | จำเป็นเมื่อข้อจำกัดคน-ทักษะเป็นคอขวดจริง | |
| Alternative Routing / Machine Flexibility | ใช้ได้เมื่อ master data พร้อมและต้องการ balance load | |
| Meta-heuristic Optimizer (GA/Tabu, Hybrid ML-Meta) | ให้ solution ดีกว่า heuristic แต่ใช้เวลาพัฒนายาว (ScienceDirect) | |
| Multi-Objective Optimization (Energy, Cost) | ต้องมีข้อมูลต้นทุน/พลังงานครบก่อน | |
| Scenario / What-If & Versioned Plan | ดีต่อการเจรจาลูกค้า แต่ไม่กระทบ OTIF ในเฟสแรก | |
| Config-as-Code & Multi-Tenant Governance | มีประโยชน์ตอน scale SaaS; หลัง MVP ค่อยเพิ่ม |
4. Planner Apps
Core Functions
| ฟังก์ชัน | ปัจจัยสำเร็จ (Key Points) |
|---|---|
| Load Plan จาก Scheduling Engine (/solve) | เก็บเข้า jobs_plan โดย plan_version ใหม่ |
| Gantt + Drag-Drop | ถ้าเลื่อนงาน → Trigger validate_constraints() (local heuristic) |
| Lock / Unlock | ช่อง locked_by_planner กัน Engine ขยับ job ที่ล็อก |
| Multi-Scenario | Dropdown เลือก plan_version; สามารถ Compare KPI |
| Release to Shop-floor | เปลี่ยน is_released = true (+ timestamp, user_id) |
| Manual Hot-Fix | เพิ่ม/ลบ job ด่วน; ส่ง JSON ไป /partial_reschedule ถ้าต้องปรับแผน |
4.1 Planner (Gantt)
สร้าง Custom Widget + Tulip API Bot ตามตัวอย่าง “Dynamic Tulip Gantt Chart” ใน Community(community.tulip.co)
Drag-Drop เปลี่ยน planned_start แล้ว Trigger รี-คำนวณ Critical Path
5. Execution Apps – Core Functions
| ฟังก์ชัน | รายละเอียด |
|---|---|
| Job Queue | Filter: is_released = true & workstation_id = current_station |
| Start / Complete | เขียน timelogs, อัปเดต status |
| Barcode / Light Kit Pokayoke | ป้องกันหยิบผิด |
| Exception Report | Machine down → Trigger notify Planner |
| Material Issue (optional) | กดปุ่ม Backflush → POST ไป ERP |
5.2 Operator / Station Apps
แสดง Job Queue (filtered by workstation_id & planned_start)
ปุ่ม Start / Complete เก็บ Timelog, ป้องกันทำผิดขั้นตอนด้วย Device Triggers (Barcode, Light Kit)
ถ้าเครื่องมี Sensor ต่อ Edge IO → อัปเดตสถานะ Machine Attribute API อัตโนมัติ
5.3 KPI & Analytics
ใช้ Tulip Analytics ทำ Dashboard “Schedule Adherence, Capacity Utilization” แบบ Real-time
6. Feedback & Re-Schedule Loop
Machine หยุด/ช้า → Edge Device ส่ง Event → Trigger ปรับ end_actual, คำนวณ Delay
ถ้า Delay > SLA → Trigger เรียก Optimizer ให้ Re-schedule เฉพาะ Jobs ที่เหลือ
ทุกรอบ Scheduling บันทึกลง sync_log เพื่อ Audit (21 CFR Part 11, ISO9001)
7. Implementation Roadmap
| Phase | เป้าหมาย | Key Tasks / Tulip Feature |
|---|---|---|
| 0 – Foundation | Data Model & Connectivity | Create Tables, HTTP Connector, Table API Upsert |
| 1 – MVP | Simple Forward Schedule | Timer Trigger, Planner Gantt Widget |
| 2 – Shop-floor Loop | Feedback & OEE | Edge MC, Machine Attributes, Timelogs |
| 3 – Full APS | Constraint Solver + Auto Re-schedule | External Optimizer, Rule Engine Tables |
| 4 – Optimization | KPI & Continuous Improvement | Tulip Analytics, “What-If” Scenario Apps |
8. Best-Practice Checklist
Upsert-Only—ใช้ primary keys (order_no, product_code) ทุก call API เพื่อป้องกัน duplication
Soft-Delete—เพิ่ม is_archive flag ตามแนวทาง traceability ของ Tulip Table (ไม่ลบจริง)
Connector Host ขนาดพอเหมาะ—Edge IO หรือ EC2 t3.medium รองรับ HTTP/SQL/OPC พร้อมกันได้ง่าย(softwareconnect.com)
Role-Based UI—Planner, Supervisor, Operator ใช้ Tulip Workspace/Groups แยกสิทธิ์การเห็นข้อมูล
Security—Bearer Token + HTTPS ทุก Connector ตาม REST Best-Practice
บทสรุป
Tulip มีทุกสิ่งที่ APS ต้องการ—Tables สำหรับข้อมูล, Connectors สำหรับแลกเปลี่ยน, Triggers สำหรับ Logic, Edge Devices สำหรับ Machine Data, และ Analytics สำหรับ KPI. เมื่อผนวก Optimizer ภายนอก (ถ้าจำเป็น) และ UI แบบ Gantt คุณจะได้ APS ระบบเปิด (Composable) ที่ “คลิก–ลาก–วาง” ได้จริงบน Shop-floor ภายในเวลาไม่กี่สัปดาห์ 🚀