เจาะระบบ simpliMES: MES แบบ Django Core เดียว รองรับทั้งการผลิตแบบ Discrete และ Batch

September 7, 2026

การพูดคุยเรื่องดิจิทัลทรานส์ฟอร์เมชันในโรงงานมักติดขัดที่จุดเดียวกันเสมอ: ERP รู้ว่าต้องผลิตอะไร เครื่องจักรรู้ว่ากำลังเกิดอะไรขึ้นจริง แต่ไม่มีอะไรอยู่ตรงกลางที่แปลงข้อมูลสองฝั่งนี้เข้าหากันแบบเรียลไทม์ นี่คือช่องว่างที่ Manufacturing Execution System (MES) ถูกสร้างขึ้นมาเพื่อปิด — ตามมาตรฐาน ISA-95 เรียกว่า Level 3 อยู่ระหว่างระบบวางแผนระดับ Level 4 กับการควบคุมหน้างานระดับ Level 1–2

simpliMES คือคำตอบของ Simplico สำหรับช่องว่างนี้ เป็นแกนกลาง MES แบบ on-premise ตัวเดียวที่รองรับทั้งการผลิตแบบ discrete (งานกลึง ประกอบ บรรจุภัณฑ์) และแบบ batch (heat-treat เคมี กระบวนการผลิตต่อเนื่อง) ผ่านโมเดลข้อมูลและเอนจินการทำงานชุดเดียวกัน แทนที่จะแยกทำสองระบบแล้วเชื่อมต่อกันทีหลัง บทความนี้จะพาไปดูสิ่งที่ถูกสร้างขึ้นจริง — การตัดสินใจด้านสถาปัตยกรรม ประสบการณ์ของผู้ปฏิบัติงาน การเก็บข้อมูล และฟีเจอร์ AI หนึ่งเดียวในระบบ — พร้อมระบุชัดเจนว่าอะไรใช้งานได้แล้วในวันนี้ และอะไรยังอยู่ในแผนพัฒนา ซึ่งเป็นประเด็นสำคัญโดยเฉพาะเมื่อพิจารณาการปฏิบัติตาม พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล (PDPA) และ มาตรา 59 ของพระราชบัญญัติการรักษาความมั่นคงปลอดภัยไซเบอร์ สำหรับข้อมูลการผลิตที่เก็บไว้ในโรงงาน รวมถึงกรณีที่โรงงานอยู่ในเขตส่งเสริมของ BOI/EEC ซึ่งมักมีเงื่อนไขด้านการรายงานข้อมูลการผลิตที่ต้องพิสูจน์ได้

1. simpliMES คืออะไรกันแน่

  • ISA-95 Level 3 รับใบสั่งผลิตจาก Level 4 (ERP ที่จัดการวางแผน จัดซื้อ และการเงิน) แล้วขับเคลื่อนการทำงานจริงกับอุปกรณ์ระดับ Level 1–2 อย่าง PLC เครื่องมือวัด และ SCADA
  • หนึ่งสแต็กต่อหนึ่งไซต์ แบบ on-premise แต่ละโรงงานรัน Docker Compose stack ของตัวเอง ไม่พึ่งพาคลาวด์ ไม่ใช่ multi-tenant SaaS — หน้างานยังทำงานต่อได้แม้อินเทอร์เน็ตล่ม
  • เป็นผลิตภัณฑ์ ไม่ใช่โปรเจกต์เฉพาะกิจ การเชื่อมต่อ ERP ทำผ่าน connector contract เท่านั้น ดังนั้นไม่ว่าจะเป็น ERPNext, SAP, Odoo หรือแม้แต่ไฟล์ CSV ก็เป็นแค่ connector คนละแบบ ไม่มีสมมติฐานเฉพาะของ ERP ใดรั่วไหลเข้าไปในแกนระบบ
  • Discrete และ Batch อยู่ในโมเดลเดียวกัน งานกลึง ประกอบ และบรรจุภัณฑ์ ใช้โมเดล WorkOrder และ step ชุดเดียวกับงาน heat-treat เคมี และ batch กระบวนการต่อเนื่อง โดยมี run engine ตัวเดียวขับเคลื่อนทั้งคู่

ควรทำความเข้าใจขอบเขตให้ชัดเจน เพราะ Simplico มีผลิตภัณฑ์ในกลุ่มนี้อีกสองตัว: simpliMES Lite คือแพ็กเกจที่เบากว่า ติดตั้งเร็วกว่า เหมาะกับ SME ที่เพิ่งเริ่มก้าวแรกของการทำดิจิทัล ส่วนชั้น IMCS/simpliInterface ของ simpliFactory แก้ปัญหาเฉพาะเรื่องการเชื่อมต่อวัดค่าและการเชื่อมต่อหน้างาน ในขณะที่ simpliMES คือแกนระบบเต็มรูปแบบสำหรับโรงงานที่ต้องการทั้งการสั่งงาน (work-order dispatch), การตามสอบย้อนกลับ (genealogy) และการเชื่อมต่ออุปกรณ์หลายโปรโตคอลในระบบเดียว

2. สถาปัตยกรรม: การตัดสินใจที่กำหนดทุกอย่างที่ตามมา

การตัดสินใจ ทำไมถึงสำคัญ
Modular monolith แอปหลักตัวเดียวที่ deploy ได้ (Django) โดยมีขอบเขตโมดูลภายในที่เข้มงวด — โมดูลคุยกันผ่าน service function ที่เปิดเผยและ event bus ภายในโปรเซสเท่านั้น ไม่เคย import โมเดลของกันและกันโดยตรง รันง่าย แต่ยังแก้ไขได้สะอาด
แยกโปรเซสสำหรับ Edge I/O การสื่อสารกับอุปกรณ์รันในเซอร์วิส async แยกต่างหาก (connector) แยกจากวงจรชีวิตของเว็บแอป รีสตาร์ท UI ได้โดยไม่เสียข้อมูลแม้แต่ค่าเดียว
Store-and-forward ที่ edge ทุกค่าที่อ่านได้จะถูกเขียนลง disk spool ก่อนพยายาม publish ทุกครั้ง หาก broker หรือ core ล่ม ข้อมูลจะสะสมบน disk แล้ว replay ตามลำดับเมื่อการเชื่อมต่อกลับมา การรับข้อมูลออกแบบให้ idempotent ทำให้ replay ปลอดภัย การไม่สูญเสียข้อมูลการผลิตคือข้อกำหนดด้านการออกแบบ ไม่ใช่แค่ความหวัง
Config ของ connector จัดการผ่านฐานข้อมูล Core คือแหล่งข้อมูลจริงเพียงแหล่งเดียวว่า connector แต่ละตัวต้อง poll อะไรบ้าง เพิ่ม tag ผ่าน UI แล้ว background job จะ republish config เต็มรูปแบบไปยัง retained MQTT topic; connector จะ hot-reload driver โดยไม่ต้องรีสตาร์ท และยัง cache config ไว้บน disk เพื่อให้เริ่มทำงานได้แม้ core จะออฟไลน์
โมเดลข้อมูลเดียว สองเส้นทางการทำงาน โหมดของ work order คือ discrete หรือ batch การ release จะสร้าง step จาก routing (discrete) หรือ process spec (batch) run engine ตัวเดียวกันขับเคลื่อนทั้งคู่ โดย batch run จะตรวจสอบ telemetry สดเทียบกับ spec limit เพิ่มเติม
เชื่อมโยง telemetry กับ work order ด้วยเวลา ไม่มี foreign key จากค่าที่อ่านได้ไปยัง run โดยตรง แต่ค่าที่อ่านได้จะถูกเชื่อมโยงกับ run ผ่านการ query ช่วงเวลาที่อ้างอิงจาก event เริ่มต้นและสิ้นสุดของ run — การออกแบบนี้ทนทานต่อการ replay และความคลาดเคลื่อนของนาฬิกา
flowchart TD
    ERP["ERP ระดับวางแผน Level 4"]
    CORE["แกน simpliMES Django domain logic"]
    MQTT["MQTT broker Mosquitto"]
    CONN["โปรเซส connector asyncio edge IO"]
    TS["TimescaleDB tag samples"]
    PLC["PLC และเครื่องมือวัด OPC UA S7 Modbus"]

    ERP -->|"work orders"| CORE
    CORE -->|"ผลลัพธ์และ sync log"| ERP
    CORE -->|"published config"| MQTT
    MQTT -->|"config hot reload"| CONN
    CONN -->|"readings"| MQTT
    MQTT -->|"tag events"| CORE
    CORE --> TS
    CONN --> PLC
    PLC --> CONN

หนึ่งไซต์ประกอบด้วยสี่โปรเซส: core (Django — UI, API, domain logic), connector (asyncio — edge I/O), Celery worker และ MQTT consumer โครงสร้างพื้นฐานคือ PostgreSQL + TimescaleDB, Redis และ Mosquitto core กับ connector สื่อสารกันผ่าน MQTT เท่านั้น ไม่เคยเรียก API กันตรง ๆ ซึ่งเป็นสิ่งที่ทำให้ทั้งคู่รีสตาร์ทแยกจากกันได้อย่างอิสระ

3. ใบสั่งผลิตและการจ่ายงาน

ใบสั่งผลิตนำเข้าจาก ERP หรือสร้างด้วยมือก็ได้ การ release จะสร้าง step จาก routing และ operation ของสินค้า (discrete) หรือ process spec (batch) กระดาน dispatch แสดงงานที่ปล่อยแล้วเรียงตาม work center และ step จะเลื่อนขั้นอัตโนมัติ — เมื่อ step หนึ่งเสร็จ step ถัดไปก็พร้อม และใบสั่งผลิตจะเสร็จสมบูรณ์เมื่อ step สุดท้ายเสร็จ

4. Operator Terminal: kiosk จริง ไม่ใช่หน้าจอเดสก์ท็อปย่อส่วน

หน้าจอ kiosk แบบไร้ chrome สัมผัสง่าย อยู่ที่ /execution/terminal/ แยกออกจาก UI ของฝ่ายบริหารโดยตั้งใจ:

  • Terminal ผูกกับ workstation เพียงครั้งเดียว ผู้ปฏิบัติงานยืนยันตัวตนด้วยบัตรหรือรหัสพนักงานพร้อม PIN ต่อกะ
  • ขั้นตอนคือ เลือกงานและเครื่องจักร จากนั้น start → รายงานจำนวนหรือของเสียพร้อมเหตุผล → pause หรือ resume → complete ทุกการแตะจะ post ไปยัง service และ re-render เพียงหนึ่งพาเนล ไม่มีการเปลี่ยนหน้าระหว่างงาน
  • สำหรับ batch run พาเนลจะแสดง ค่าพารามิเตอร์กระบวนการสดเทียบกับขีดจำกัดตาม spec เช่น อุณหภูมิการแช่ สถานะประตูเตา และค่าอื่น ๆ ที่ดึงจาก telemetry ของเครื่องระหว่าง run
  • ทุกการกระทำเป็น transactional เขียน audit entry และ publish domain event พร้อมการระบุที่มาครบถ้วน: ผู้ปฏิบัติงานคนไหน workstation ไหน run ไหน — ซึ่งเป็นข้อมูลสำคัญเมื่อโรงงานต้องพิสูจน์ auditability ตาม PDPA และมาตรา 59

5. การเก็บข้อมูลอัตโนมัติ ครอบคลุมสามโปรโตคอล

  • สามโปรโตคอลอุตสาหกรรม ใช้งานได้จริงวันนี้: OPC-UA, Siemens S7 และ Modbus TCP/RTU แต่ละไดรเวอร์ normalize เป็น tag model กลาง — ค่าที่อ่านได้พร้อม equipment, tag key, timestamp ต้นทาง, ค่าตัวเลขหรือข้อความ และ quality
  • ค่าที่อ่านได้จะถูกเก็บใน TimescaleDB hypertable โดย key คือ tag และเวลา
  • การป้อนข้อมูลด้วยมือ รองรับอุปกรณ์ที่ไม่มีอินเทอร์เฟซดิจิทัล
  • การบันทึก downtime พร้อมรหัสเหตุผล ขับเคลื่อนสถานะสดของเครื่องจักรและป้อนข้อมูลให้ dashboard สไตล์ OEE

นี่คือปัญหาความหลากหลายของโปรโตคอลแบบเดียวกับที่เราเคยเขียนถึงแยกต่างหาก — หน้างานส่วนใหญ่พูดได้ห้าภาษาพร้อมกันจริง ๆ และ edge connector ของ simpliMES ก็เป็นหนึ่งในสองจุด (ควบคู่กับ simpliInterface ของ simpliFactory) ที่ Simplico สร้างชั้นเชื่อมต่อเพื่อแก้ปัญหานี้จริง

6. อุปกรณ์: ลำดับชั้น สถานะสด และผังโรงงานที่ใช้งานได้จริง

  • ลำดับชั้น ตาม ISA-95 — site, area, line, cell, unit — อธิบายด้วยภาษาที่เข้าใจง่าย ไม่ใช้ศัพท์มาตรฐานล้วน ๆ
  • บอร์ดสถานะสด แสดงสถานะปัจจุบันของเครื่องจักรทุกเครื่อง (running, idle, down, setup) จัดกลุ่มตาม area และ connector รีเฟรชอัตโนมัติ
  • สถานะสดขับเคลื่อนด้วย event ไม่ใช่การ polling: เมื่อ run เริ่ม เครื่องเปลี่ยนเป็น running เมื่อจบเปลี่ยนเป็น idle เมื่อเปิด downtime เปลี่ยนเป็น down (พร้อมเหตุผล) และเมื่อปิดจะกลับเป็น running หากยังมี run ทำงานอยู่ โมดูล equipment ดูแลสิ่งนี้เพียงแค่ตอบสนองต่อ execution event บน bus เท่านั้น
  • ผังโรงงาน แสดงตำแหน่งจริงของเครื่องจักรแต่ละเครื่อง ไล่สีตามสถานะสด วิศวกรวางตำแหน่งเครื่องจักรด้วยการลากในโหมดแก้ไข ตำแหน่งจะถูกบันทึกเป็นพิกัดที่มี audit trail บนเรคคอร์ดของอุปกรณ์
  • การสอบเทียบและบำรุงรักษา ครอบคลุมเรคคอร์ดการสอบเทียบทั่วไปพร้อมวันครบกำหนด บันทึกเหตุการณ์บำรุงรักษา และเอกสารอ้างอิงต่อเครื่อง — คู่มือ สเปคชีต — พร้อมการดึงข้อความ

7. การตามสอบย้อนกลับ (Genealogy) — สร้างเสร็จบางส่วน และเราบอกตรง ๆ

โมเดลข้อมูลสำหรับ lot/serial ของวัตถุดิบ, บันทึกการใช้วัตถุดิบ (ใบสั่งผลิตใช้อะไรไปบ้าง) และการเชื่อมโยง lot จากแม่สู่ลูก ถูกสร้างขึ้นแล้ว — เป็นแกนหลักสำหรับการตามสอบย้อนกลับแบบ as-built ของใบสั่งผลิตหรือ batch กลับไปยังวัตถุดิบและอุปกรณ์ที่ใช้ ส่วนที่ยังอยู่ระหว่างเชื่อมต่อสำหรับรุ่นถัดไปคือการสร้างลิงก์อัตโนมัติเมื่อ run เสร็จสิ้น รวมถึง UI สำหรับตามสอบไปข้างหน้า/ย้อนกลับ และรายงานตามสอบฉบับเต็ม หากการประเมินของคุณต้องพึ่งพารายงาน genealogy ฉบับสมบูรณ์วันนี้ นี่คือจุดเดียวที่ควรถามให้ชัดก่อนปิดขอบเขตงาน — โดยเฉพาะหากโรงงานอยู่ภายใต้ข้อกำหนดการตรวจสอบย้อนกลับตาม BOI/EEC

8. AI Analyze: แผง local LLM ที่เลือกใช้ได้ และอยู่ on-prem ทั้งหมด

แผง "AI Analyze" ปรากฏบนหน้า run-detail, downtime-detail, equipment-detail และหน้า calibration ระดับ fleet:

  • สร้างสรุปโครงสร้างแบบกระชับสำหรับสิ่งที่กำลังดูอยู่ — สถิติ telemetry ต่อ tag, การละเมิด spec limit, event ของสถานะ downtime และการผลิต, ข้อความคัดจากเอกสารอ้างอิงที่อัปโหลด — และ ไม่เคยส่งค่าดิบ
  • สรุปนั้นถูกส่งไปยัง โมเดล Ollama ที่รันในเครื่อง (ค่าเริ่มต้นเป็นโมเดลขนาดเล็ก 3B พารามิเตอร์) งานรันเป็น background task และมีการ cache ไว้ พาเนลจะ poll จนกว่าจะพร้อม
  • เลือกใช้ได้และอยู่ on-premise ทั้งหมด — ไม่มีข้อมูลออกนอกไซต์ และหาก endpoint ของโมเดลในเครื่องเข้าถึงไม่ได้ ปุ่มจะไม่แสดงขึ้นมาเลย ซึ่งเป็นจุดสำคัญสำหรับโรงงานที่ต้องปฏิบัติตาม PDPA ในเรื่องการไม่ส่งข้อมูลออกนอกองค์กร
  • ปรับทิศทางได้สองแบบ: ผู้ปฏิบัติงานพิมพ์โน้ตข้อความอิสระได้ ("ทำไมของเสียถึงพุ่งขึ้น") และคู่มือของอุปกรณ์ที่อัปโหลดไว้จะถูกป้อนเป็นข้อมูลอ้างอิงที่โมเดลถูกกำชับให้เชื่อมากกว่าความรู้ทั่วไปของตัวเอง

นี่คือรูปแบบสถาปัตยกรรมเดียวกับที่เราอธิบายไว้สำหรับ การอ่าน log หน้างานด้วยโมเดลในเครื่องฝั่ง simpliSOC — โมเดลขนาดเล็กที่รันในเครื่อง อ่านบริบทที่มีโครงสร้าง และสร้างสรุปด้วยภาษาที่เข้าใจง่าย เป็นเพียงคำแนะนำเท่านั้น ไม่เขียนกลับไปยังอุปกรณ์ใด ๆ แผง AI Analyze ของ simpliMES คือรูปแบบเดียวกันนี้ที่ใช้งานจริงภายใน MES เอง โดยเจาะจงที่ run, downtime และ calibration แทนที่จะเป็น security alert

9. การเชื่อมต่อ ERP: connector contract ไม่ใช่แกนระบบที่ยึดติดกับ ERP ใดโดยเฉพาะ

  • Connector contract เดียว (ErpConnector) คือช่องทางเดียวที่ ERP จะแตะต้อง simpliMES ได้ implementation แต่ละตัว self-register เอง ERPNext เป็น reference implementation และมี generic REST connector มาให้ด้วย
  • การดึงข้อมูลตามตารางเวลาขับเคลื่อน connector และ upsert ผ่าน masterdata และ dispatch service โดยเขียน sync-log หนึ่งแถวต่อหนึ่ง entity — เพื่อไม่ให้การ sync ที่ล้มเหลวของรายการเดียวถูกซ่อนอยู่ในข้อความสำเร็จระดับ batch
  • ERPNext webhook endpoint รับ event ของ Work Order โดยยืนยันตัวตนด้วย shared token แบบ constant-time
  • สมมติฐานเรื่อง field-map ที่ยังต้องได้รับการยืนยันจากลูกค้ารายใดรายหนึ่งจะถูกทำเครื่องหมายไว้ในโค้ดโดยตรงและระบุไว้ใน connector spec — ไม่ปล่อยให้เป็นความเข้าใจโดยนัย

10. รายงาน สองประสบการณ์เว็บ และการตั้งค่าที่แก้ไขได้แบบสด

  • ใบรับรอง batch และคุณภาพ render เป็น PDF ผ่าน background task
  • Dashboard ในแอป สร้างด้วย HTMX แบบ server-rendered ครอบคลุมสี่ tile: production (สถานะใบสั่งผลิต, run ที่กำลังทำงาน, ครบ/เลยกำหนด), equipment (โดนัท running/idle/down, downtime ปัจจุบัน), today (ของดี/ของเสีย, downtime ตามเหตุผล) และ attention (การสอบเทียบที่เลยกำหนด, sync error, ใบสั่งผลิตที่ค้าง)
  • Metabase มาเป็น container แยกต่างหากที่เชื่อมกับฐานข้อมูลผ่าน role แบบอ่านอย่างเดียว สำหรับ BI เฉพาะกิจที่ dashboard ชุดตายตัวคาดการณ์ไม่ได้
  • สองประสบการณ์เว็บที่แยกกันชัดเจนสำหรับสองกลุ่มผู้ใช้: staff shell — เมนูซ้าย server-rendered กรองตาม role พร้อม tooltip ทุกรายการ — และ operator kiosk ที่กล่าวถึงข้างต้น เข้าถึงได้โดยไม่ต้อง login ของฝ่ายบริหาร
  • หน้าตั้งค่าที่แก้ไขได้แบบสด ครอบคลุมโมเดล URL และ timeout ของ AI Analyze, ข้อมูลประจำไซต์ และการเลือกว่าการเปลี่ยนแปลงอุปกรณ์หรือ tag จะ auto-publish config ของ connector หรือไม่ — ทั้งหมดโดยไม่ต้อง redeploy

11. อะไรอยู่ใน v1 และอะไรจงใจเลื่อนออกไป

ความชัดเจนในเรื่องนี้สำคัญกว่าฟีเจอร์เดี่ยว ๆ เพราะการอ้างฟีเจอร์ในแผนพัฒนาว่าเป็นความสามารถปัจจุบันคือวิธีที่เร็วที่สุดที่จะเสียความไว้วางใจของโรงงานระหว่างการติดตั้งจริง โดยเฉพาะในบริบทที่ต้องรายงานความสามารถของระบบตามข้อกำหนด BOI/EEC หรือการตรวจสอบภายในของโรงงาน

สร้างเสร็จใน v1: การจ่ายงานและการทำงานของใบสั่งผลิตทั้งแบบ discrete และ batch, การเก็บข้อมูลอัตโนมัติครอบคลุมสามโปรโตคอลบวกการป้อนข้อมูลด้วยมือและการบันทึก downtime, ลำดับชั้นอุปกรณ์เต็มรูปแบบพร้อมสถานะสด ผังโรงงาน การสอบเทียบและบำรุงรักษา, การตามสอบย้อนกลับและการติดตามการใช้วัตถุดิบขั้นพื้นฐาน, ใบรับรอง batch, ชุด dashboard ในแอป, การเชื่อมต่อ ERPNext และ generic-REST, และแผง AI Analyze แบบ local LLM

เลื่อนไปรุ่นถัดไป: UI ตามสอบไปข้างหน้า/ย้อนกลับและรายงานตามสอบฉบับเต็ม, การนำเข้าข้อมูลผ่านไฟล์/CSV และ REST-webhook, การตรวจสอบคุณภาพระหว่างกระบวนการ, workflow การจัดการของไม่ตรงข้อกำหนดและการกักกัน, ชุด dashboard OEE เต็มรูปแบบ, แพ็กเกจการปฏิบัติตามมาตรฐานเฉพาะทาง (AMS2750, CQI-9 pyrometry), SPC, การรวมข้อมูลหลายไซต์ และการจัดตารางแบบ finite-capacity

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

simpliMES ตามสอบย้อนกลับไปข้างหน้าและข้างหลังได้เต็มรูปแบบวันนี้หรือไม่?
ข้อมูลพื้นฐาน — lot, serial, การใช้วัตถุดิบ, ลิงก์แม่-ลูก — ถูกเก็บอยู่แล้ววันนี้ แต่ UI ตามสอบและรายงานตามสอบฉบับเต็มที่ดึงข้อมูลเหล่านี้ยังอยู่ระหว่างพัฒนา และมีกำหนดในรุ่นถัดไป ไม่ใช่รุ่นปัจจุบัน

แผง AI Analyze เคยสั่งงานอุปกรณ์หรือเปลี่ยน setpoint หรือไม่?
ไม่เคย มันอ่านสรุปที่มีโครงสร้างและสร้างข้อความ — คำอธิบายด้วยภาษาที่เข้าใจง่าย และในบางกรณีจะแนะนำจุดที่ควรโฟกัส ไม่เคยเขียนกลับไปยัง PLC ไม่เคยปรับ setpoint และไม่เคยปิดเคสใดโดยอัตโนมัติ มนุษย์เป็นผู้อ่านและตัดสินใจ

simpliMES ทำงานได้โดยไม่ต้องเชื่อมต่อ ERP เลยหรือไม่?
ได้ ใบสั่งผลิตสร้างด้วยมือภายใน simpliMES ได้ตามปกติ connector ของ ERP เป็นส่วนเสริม ไม่ใช่ dependency ที่จำเป็นสำหรับการทำงานประจำวัน

simpliMES มี SPC หรือ OEE เต็มรูปแบบมาให้เลยหรือไม่?
ยังไม่มี มุมมองสไตล์ OEE มีอยู่แล้ววันนี้ผ่าน dashboard tile และการติดตามสถานะสดของอุปกรณ์ แต่ชุด dashboard OEE เต็มรูปแบบและ statistical process control อยู่ในรายการที่เลื่อนไปรุ่นถัดไป

12. Simulator และเส้นทางสู่การเดโมจริง

ในตัว repository มี device simulator ให้ — เตาเผา OPC-UA, เครื่องอัด Modbus, เตาอบชุบ S7 — แต่ละตัวขับเคลื่อนค่าผ่าน registry ร่วมที่ปรับค่าเข้าหาเป้าหมายพร้อม noise ที่สมจริง บวกกับ web control panel ที่มี manual override ต่อสัญญาณและปุ่ม scenario ต่ออุปกรณ์ (heat, soak, cool, jam, overheat) โหมด autopilot รันหน้างานจำลองทั้งหมดผ่านสถานการณ์ที่สมจริงตามระยะเวลาที่กำหนดแล้วพักทุกอย่างไว้ที่สถานะนิ่ง — มีประโยชน์สำหรับการเดโม การฝึกอบรม หรือการนำเสนอขายที่ต้องการระบบที่ทำงานจริงโดยไม่ต้องมีโรงงานจริงอยู่เบื้องหลัง

13. การติดตั้งใช้งานและสแต็กเทคโนโลยี สำหรับคนที่ต้องดูแลจริง

หนึ่ง Docker Compose stack ต่อหนึ่งไซต์โรงงาน: core, connector, worker, MQTT consumer, PostgreSQL/TimescaleDB, Redis, Mosquitto, Caddy และ Metabase Caddy ทำหน้าที่ terminate TLS และ reverse-proxy ส่วน connector จะ cache config และ spool ค่าที่อ่านได้ลง disk เพื่อให้ไซต์รอดจากช่วงที่ core ปิดซ่อมบำรุงโดยไม่เสียข้อมูล

ชั้น ตัวเลือกที่ใช้
แอปหลัก Python 3.12, Django 5, Django REST Framework
Edge connector asyncio, ไลบรารีไคลเอนต์ OPC-UA/Modbus/S7, SQLite spool ในเครื่อง
Messaging MQTT (Mosquitto) — ช่องทางเดียวระหว่าง core กับ connector
Time-series PostgreSQL + TimescaleDB hypertables
Async work Celery + Redis พร้อม scheduled job สำหรับงานตามรอบเวลา
Local LLM Ollama เลือกใช้ได้ อยู่ on-premise
UI Django template แบบ server-rendered + HTMX ไม่มี CDN ไม่มี JS framework
รายงาน สร้าง PDF, Metabase สำหรับ BI

14. จุดที่ระบบนี้เข้ากับโปรเจกต์จริง

simpliMES ไม่ใช่ SKU สำเร็จรูป — แต่กำหนดขอบเขตต่อโรงงานแต่ละแห่ง และ บริการพัฒนา MES ของ Simplico วางระดับ tier ราคา และแผน pilot รายสัปดาห์ไว้สำหรับงานลักษณะนี้โดยเฉพาะ หากหน้างานของคุณผสมทั้งโปรโตคอลและรุ่นเครื่องจักรอยู่แล้ว — ปัญหาห้าภาษาที่หน้างานพูดพร้อมกัน — นั่นคือขอบเขตของ edge layer ที่ simpliMES ถูกสร้างมาเพื่อรองรับโดยตรง

ติดต่อทีมงานได้ที่ hello@simplico.net โทรหรือ WhatsApp ที่ (+66) 97 496 6397 หรือ LINE ไอดี iiitum1984


แหล่งที่มา:

Ready to talk about your project?

Share goals and constraints. We'll assemble architects and engineers to move fast with you.

Get in touch