คนทำ IoT โรงงานส่วนใหญ่ติดอยู่ที่ขั้นเดียวกัน — เก็บข้อมูลได้แล้ว ทำกราฟสวยแล้ว แจ้งเตือนตอนค่าเกินได้แล้ว แต่การแจ้งเตือนตอนค่าเกินคือการบอกว่า “มันพังไปแล้ว”
บทความนี้เล่าวิธีที่ผมใช้เปลี่ยนสัญญาณเปิด-ปิดธรรมดา ให้กลายเป็นตัวชี้ว่าเครื่องกำลังเสื่อม — โดยไม่ต้องติดเซนเซอร์เพิ่มแม้แต่ตัวเดียว
หลักคิด
ถ้าเครื่องจักรของคุณมี ส่วนที่ทำงานตลอด กับ ส่วนที่ทำงานเป็นช่วงตามความต้องการ คุณมีดัชนีสุขภาพอยู่ในมือแล้ว
ตัวอย่างที่ผมดูแลคือเตาน้ำมันที่มีหัวฉีดสองหัว:
- หัวที่ 1 — เปิดตลอดเวลาที่เตาเดิน เป็นไฟพื้นฐาน
- หัวที่ 2 — ตัวควบคุมอุณหภูมิสั่งเปิด-ปิดเป็นจังหวะ เติมความร้อนเท่าที่ขาด
สัดส่วนเวลาที่หัวที่ 2 ต้องทำงาน (duty cycle) คือคำตอบของคำถามว่า “เตาต้องออกแรงเพิ่มแค่ไหนถึงจะรักษาอุณหภูมิไว้ได้”
เครื่องที่สมบูรณ์ใช้แรงน้อย เครื่องที่เริ่มเสื่อมต้องใช้แรงมากขึ้นเรื่อย ๆ เพื่อผลลัพธ์เท่าเดิม — เหมือนคนที่ปอดเริ่มไม่ดี เดินระยะเท่าเดิมแต่หอบมากขึ้น
หลักการนี้ใช้ได้กับอะไรก็ตามที่มีโครงสร้างแบบเดียวกัน: ปั๊มตัวหลัก/ตัวเสริม, คอมเพรสเซอร์หลายสเตจ, ฮีตเตอร์ที่มีหลายชุด, ชิลเลอร์ที่มีคอมหลายตัว
ตัวเลขจริง
นี่คือข้อมูลที่ผมดึงย้อนหลังจากฐานข้อมูล ทุกแถวเทียบที่ อุณหภูมิเป้าหมายเดียวกัน และเลือกเฉพาะชั่วโมงที่หัวที่ 1 เดินเต็ม 100%:
| วันที่ | duty% ของหัวที่ 2 |
|---|---|
| 14 ส.ค. | 47.0% ← ต่ำสุด |
| 15 ส.ค. | 51.4% |
| 16 ส.ค. | 50.6% |
| 25 ส.ค. | 61.6% |
| 27 ส.ค. | 63.0% |
| 28 ส.ค. | 65.8% |
| 29 ส.ค. | 72.5% |
| 30 ส.ค. | 77.2% ← วันก่อนเปลี่ยนปั๊ม |
ไต่จาก 47% เป็น 77% ในเวลา 16 วัน ที่เงื่อนไขเดียวกันทุกอย่าง
ที่น่าสนใจคือ ข้อมูลเริ่มส่งสัญญาณตั้งแต่วันที่ 24–25 แต่คนที่เดินผ่านเครื่องทุกวันเพิ่งรู้สึกว่า “ปั๊มเริ่มไม่ดี” ในวันที่ 27 — ข้อมูลเห็นก่อนสองถึงสามวัน และถ้ามีระบบเฝ้าตัวเลขนี้ไว้ จะเห็นก่อนกว่านั้นอีก
วิธีคำนวณ
ถ้าคุณเก็บสถานะเปิด-ปิดเป็น 0/1 ลงฐานข้อมูลอนุกรมเวลาอยู่แล้ว ก็แค่หาค่าเฉลี่ย เพราะค่าเฉลี่ยของ 0 กับ 1 คือสัดส่วนเวลาที่เป็น 1 พอดี
| |
แล้วกรองก่อนเอาไปเทียบ:
| |
สามข้อที่ทำให้ตัวเลขเชื่อถือได้
1. เทียบที่เงื่อนไขเดียวกันเสมอ
duty cycle ขึ้นกับ setpoint และปริมาณงานโดยธรรมชาติ ถ้าเอาวันที่ตั้งอุณหภูมิ 190°C ไปเทียบกับวันที่ตั้ง 195°C แล้วสรุปว่าเครื่องเสื่อม จะได้ข้อสรุปผิดทันที
ต้องแยกกลุ่มตาม setpoint ก่อน แล้วเทียบกันเฉพาะภายในกลุ่มเดียวกัน
2. ตัดช่วงที่ข้อมูลไม่ครบทิ้ง
ถ้าอุปกรณ์หลุด WiFi ไปครึ่งวัน ค่าเฉลี่ยของวันนั้นจะมาจากตัวอย่างครึ่งเดียว — อาจสูงหรือต่ำผิดปกติโดยไม่มีอะไรเสียเลย
ผมนับจำนวนตัวอย่างต่อชั่วโมงแล้วทิ้งชั่วโมงที่ได้ไม่ถึง 70% ของที่ควรจะเป็น
3. ดูแนวโน้มหลายวัน อย่าตัดสินจากวันเดียว
duty ของวันเดียวแกว่งได้ตามอากาศ ความชื้นของวัตถุดิบ หรือรอบการผลิต สิ่งที่มีความหมายคือทิศทางที่ไต่ขึ้นต่อเนื่องหลายวัน ไม่ใช่ค่าสูงวันเดียว
ตั้งเกณฑ์เตือนยังไง
ให้ข้อมูลบอกเอง อย่าเดา:
- เก็บข้อมูลช่วงที่เครื่องยังสมบูรณ์แน่ ๆ (เช่นหลังเปลี่ยนอะไหล่ใหม่) สัก 2 สัปดาห์ → ได้ค่าฐาน
- ตั้งเส้นเตือนไว้ประมาณ ค่าฐาน + 20–25%
- เตือนเมื่อค่าเฉลี่ย 3 วันเกินเส้น ไม่ใช่เตือนทันทีที่วันเดียวเกิน
จากตัวเลขข้างบน ค่าฐานอยู่ราว 47–55% ผมจึงตั้งเส้นเตือนไว้ที่ 65% — ซึ่งถ้ามีระบบนี้ตั้งแต่แรก มันจะเตือนตั้งแต่วันที่ 27 ก่อนที่จะต้องรีบหาอะไหล่มาเปลี่ยนแบบฉุกเฉิน
ตัวชี้วัดที่ลองแล้วใช้ไม่ได้
เพื่อความเป็นธรรม ผมลองตัวอื่นด้วยและมันไม่เวิร์ก
เวลาที่ใช้ไต่อุณหภูมิจากเย็นถึงจุดทำงาน — ฟังดูน่าจะเป็นดัชนีที่ดี เพราะเครื่องเสื่อมควรไต่ช้าลง แต่พอวัดจริง 30 วันได้ค่ากระจายตั้งแต่ 16 นาทีถึง 142 นาที เพราะมันขึ้นกับปริมาณของที่อยู่ในเตารอบนั้นมากเกินไป ไม่มีการทำให้เป็นมาตรฐาน ก็เทียบกันไม่ได้
บทเรียนคือ ตัวชี้วัดที่ดีต้องหารด้วยตัวแปรที่มันขึ้นอยู่ด้วยให้หมดก่อน duty cycle ใช้ได้เพราะเราตรึง setpoint และสถานะเดินเต็มกำลังไว้แล้ว ส่วนเวลาไต่อุณหภูมิยังมีตัวแปร “ปริมาณงาน” ที่ตรึงไม่ได้
เริ่มยังไงถ้ายังไม่เคยทำ
ไม่ต้องลงทุนอะไรเพิ่มเลย:
- หาส่วนที่ทำงานเป็นช่วง ในเครื่องที่คุณเก็บข้อมูลอยู่แล้ว — วาล์ว รีเลย์ ฮีตเตอร์เสริม ปั๊มตัวที่สอง
- หาค่าเฉลี่ยรายชั่วโมง ของสถานะเปิด-ปิดตัวนั้น
- แยกกลุ่มตามเงื่อนไขการทำงาน แล้วพล็อตย้อนหลัง 30 วัน
- ดูว่ามีแนวโน้มไต่ขึ้นไหม
ถ้ามีแนวโน้มขึ้นชัด ๆ ทั้งที่เงื่อนไขเหมือนเดิม — นั่นคือเครื่องกำลังบอกอะไรบางอย่างกับคุณอยู่ ก่อนที่มันจะพัง
ข้อมูลในบทความมาจากเครื่องจักรที่ผมดูแลอยู่ ตัวเลขที่แสดงเป็นค่า duty cycle ล้วน ๆ ไม่มีข้อมูลการผลิตหรือข้อมูลของสถานประกอบการใด ๆ