PinPrint

ทำไมโรงงานปี 2026 ยังต้องกังวลเรื่อง “ความหน่วงแบบสุ่ม” บน Edge Computer

เมื่อคุณย้ายงานควบคุม การวิเคราะห์ หรือการตรวจจับความผิดปกติ จาก PLC/DCS ลงมาที่ Edge Computer ที่ใช้ระบบปฏิบัติการ Linux ทั่วไป สิ่งหนึ่งที่มักถูกมองข้ามคือ Scheduling Latency แบบสุ่ม (Jitter) — ความหน่วงระหว่าง “เหตุการณ์เกิดขึ้น” กับ “โปรแกรมได้รับโอกาสประมวลผล” ซึ่งบน Linux มาตรฐานอาจแกว่งจากไมโครวินาทีหลักร้อย ไปจนถึง หลายสิบมิลลิวินาที เมื่อระบบพร้อมกันรับภาระงานอื่น เช่น การเข้ารหัส TLS, การบีบอัดไฟล์ log, หรือการอัปเดตฐานข้อมูล local

สำหรับ Dashboard หรือ Report ค่า Jitter ระดับนี้ไม่ใช่ปัญหา แต่ถ้างานนั้นคือ การปิด Interlock ภายใน 2 มิลลิวินาที, การสุ่มตัวอย่างแรงสั่นสะเทือน 1,000 ครั้ง/วินาทีแบบ sync กับมุม shaft, หรือการควบคุม Motion แบบ Soft Motion — Latency ที่แกว่ง 30 มิลลิวินาทีโดยไม่ทราบล่วงหน้า อาจหมายถึงชิ้นงานเสีย หรือแย่กว่านั้นคือความเสียหายต่อเครื่องจักร

คำตอบที่วงการ Automation ใช้กันมาหลายสิบปีคือ RTOS (Real-Time Operating System) เฉพาะทางบน MCU แต่ปัญหาเปลี่ยนไปเมื่อ Edge AI, Protocol Gateway และ Container เข้ามาอยู่ในตู้คอนโทรลเดียวกัน — คุณต้องการทั้ง Ecosystem ของ Linux (Driver, Library, Toolchain) และ Determinism ของ RTOS ในเครื่องเดียว

PREEMPT_RT ใน Linux Kernel 6.12: จุดจบของการติดตั้ง Patch เอง

เหตุการณ์สำคัญที่เปลี่ยนเกมในช่วงปลายปี 2024 คือการประกาศรวมแพตช์ PREEMPT_RT เข้าสู่ Linux Kernel 6.12 (หลังพัฒนาต่อเนื่องกว่า 20 ปี) ทำให้ Kernel หลักสามารถเปิดโหมด Fully Preemptible ได้อย่างสมบูรณ์ และ 6.12 ยังเป็น LTS (Long Term Support) ที่ได้รับการดูแลยาวนาน ซึ่งเป็นเงื่อนไขสำคัญที่ทีมวิศวกรรมของโรงงานต้องการก่อนวางระบบลง Production

ก่อนหน้านี้ ทีมที่ต้องการ Real-Time Linux ต้องเลือกระหว่าง (1) ติดตั้ง PREEMPT_RT patch เองทุกครั้งที่อัปเดต Kernel, (2) ใช้ Distribution เฉพาะทางที่ผูกกับผู้จำหน่ายรายใดรายหนึ่ง หรือ (3) ใช้ RTOS แยกต่างหาก เมื่อ RT เข้า mainline ตัวเลือกที่ 1 หายไป — ฐานโค้ดเดียวกัน ได้ทั้ง Ecosystem และ Determinism

สิ่งที่ PREEMPT_RT เปลี่ยนภายใน Kernel คือทำให้ เกือบทุกส่วนของ Kernel เองถูก preempt ได้ รวมถึง critical section ที่เคยปิด interrupt ยาวๆ โดยแทนที่ด้วย sleeping spinlock ที่สามารถถูกขัดจังหวะ และทำให้ interrupt ถูกย้ายเข้า thread ที่จัดลำดับได้ (threaded interrupt handler) — ผลลัพธ์คือค่า latency สูงสุดที่เคยเป็นมิลลิวินาที ถูกบีบให้เหลือหลักร้อยไมโครวินาที พร้อม tail latency ที่คาดการณ์ได้

กราฟเปรียบเทียบการกระจายตัวของ scheduling latency ระหว่าง kernel ปกติกับ PREEMPT_RT
ภาพประกอบ: การกระจายตัวของ Scheduling Latency แบบ cyclictest ภายใต้โหลดจำลอง — Kernel ปกติ (แดง) มี tail ยาวถึงระดับมิลลิวินาที ขณะที่ PREEMPT_RT (เขียว) กระจุกตัวหลักไม่กี่ร้อยไมโครวินาที (ตัวเลขเชิงภาพประกอบ ค่าจริงขึ้นกับฮาร์ดแวร์และโหลด)

สถาปัตยกรรมที่แยกโซน: Hard Real-Time กับ Best-Effort อยู่ด้วยกันอย่างไร

การเปิด PREEMPT_RT ทั้งเครื่องไม่ใช่คำตอบสุดท้าย — วิธีที่นิยมในระบบ Edge ระดับ Production คือ การแบ่งโซน CPU (CPU Isolation / cpu affinity) โดยสรุปคือ:

โซน งานที่อยู่ ข้อกำหนดเวลา กลไกปกป้อง
Hard RT Motion sync, Interlock logic, สุ่มสัญญาณเข้าแบบ deterministic cycle < 1 ms, jitter < 100 µs isolcpus + PREEMPT_RT + SCHED_FIFO
Soft RT Edge Analytics, Protocol translation (OPC UA ↔ MQTT), Buffer 100 ms – 1 s cgroup cpu.max + nice tuning
Best-effort Dashboard, Agent รายงานสถานะ, Log shipping, Update agent ไม่มี SLA เวลา cgroup จำกัด CPU + I/O priority
แผนภาพสถาปัตยกรรมแบ่งโซน Hard Real-Time, Edge Controller และ Cloud
ภาพประกอบ: สถาปัตยกรรมแบ่งโซนบน Edge Controller เดียว — โซน Hard RT สื่อสารวงรอบสั้นกับฟีลด์ได้เทรียร์ เมื่อขึ้นสู่คลาวด์ต้องผ่านชั้น Store-and-Forward เสมอ เพื่อไม่ให้งานควบคุมรอเครือข่าย

หัวใจของการออกแบบนี้คือหลัก “งานควบคุมต้องไม่รอเครือข่าย” — วงจร Hard RT ปิดสมบูรณ์ภายในตัว Edge Controller และฟีลด์ได้เทรียร์ ส่วนการส่งข้อมูลขึ้นคลาวด์เป็นงานแยกที่เกิดขึ้นภายหลังผ่าน buffer ถ้าอินเทอร์เน็ตขาด โรงงานยังผลิตได้ปกติ และข้อมูลจะถูกเก็บไว้ส่งภายหลัง (Store-and-Forward)

ตรวจสอบก่อนเชื่อ: วัด Determinism ของคุณเองด้วย cyclictest

กฎเหล็กของวิศวกรคือ อย่าเชื่อตัวเลขใน datasheet หรือบทความใดๆ ทั้งสิ้น จนกว่าจะวัดบนฮาร์ดแวร์ของคุณเอง และเครื่องมือมาตรฐานคือ cyclictest (rt-tests) ที่วัดตัวเลข latency จริงภายใต้โหลดจำลอง:

# วัด latency บน 8 cores พร้อมโหลดจำลองแบบเต็มรูปแบบ
cyclictest -m -Sp95 -h 400 -D24h -i200 > latency.log
#   -m : lock memory (ป้องกัน page fault)
#   -S : SMP test ครบทุก core
#   -p95 : priority 95 (สูงกว่า kernel thread ส่วนใหญ่)
#   -D24h : รันยาว 24 ชม. เพื่อจับ tail latency ที่พบยาก
# อ่านผล: ดูค่า Max และเปอร์เซ็นไทล์ 99.999% ไม่ใช่แค่ค่าเฉลี่ย

ค่าที่ต้องรายงานผู้ออกแบบระบบคือ ค่าสูงสุดใน 24 ชม. และ p99.999 ไม่ใช่ค่าเฉลี่ยหรือค่าต่ำสุด เพราะ interlock ที่พลาดแค่ครั้งเดียวใน 10 ล้านรอบ ก็เพียงพอที่จะสร้างความเสียหาย วิธีที่ถูกต้องคือกำหนด WCET (Worst-Case Execution Time) budget จากค่าที่วัดได้ บวก safety margin แล้วตรวจสอบในทุกๆ การเปลี่ยนแปลงของระบบ

Key Takeaways

  • PREEMPT_RT อยู่ใน Kernel mainline แล้วตั้งแต่ 6.12 (LTS) — ไม่ต้องติดตั้ง patch เองอีกต่อไป ฐานโค้ดเดียวได้ทั้ง Ecosystem ของ Linux และ Determinism ระดับ RTOS
  • Linux มาตรฐานมี Jitter ระดับมิลลิวินาที ภายใต้โหลดผสม ซึ่งใช้ทำ Dashboard ได้ แต่ห้ามใช้กับงาน Hard RT เช่น Interlock หรือ Motion sync
  • ออกแบบแบ่งโซน CPU (Hard RT / Soft RT / Best-effort) ด้วย isolcpus + SCHED_FIFO + cgroup แทนการหวังพึ่ง Kernel เพียงอย่างเดียว
  • วัดเองด้วย cyclictest 24 ชม. และออกแบบจากค่า Max / p99.999 ไม่ใช่ค่าเฉลี่ย — และวัดใหม่ทุกครั้งที่เปลี่ยน Kernel, Driver หรือ Workload
  • ทีมงาน Honey Corporation มีประสบการณ์ติดตั้งระบบ Edge Computing และ Protocol Gateway ในโรงงานอุตสาหกรรม รวมถึงการออกแบบโซน Hard RT สำหรับงานควบคุมควบคู่กับการเชื่อมต่อคลาวด์แบบ Store-and-Forward ให้สายการผลิตไม่หยุดแม้เน็ตขาด

Honey Corporation พร้อมให้คำปรึกษา

ทีมงานของเรามีความเชี่ยวชาญด้านระบบ Edge Computing และ Real-Time Control พร้อมออกแบบและติดตั้งระบบให้เหมาะกับธุรกิจของคุณ

📞 โทร: 09-23242995 | อีเมล: support@honey.co.th
เว็บไซต์: www.honey.co.th

PinPrint