การบำรุงรักษาตามสภาพ (CBM) 2026: แบบแปลนตรวจรับ 90 วัน
การบำรุงรักษาตามสภาพ (CBM) จะไม่ลดเวลาหยุดเครื่องเพียงเพราะติดเซนเซอร์และมีแดชบอร์ด หากการแจ้งเตือนไม่ถูกเปลี่ยนเป็นงานซ่อมที่ติดตามได้ โครงการจะเพิ่มข้อมูลแต่ไม่เพิ่มความพร้อมใช้งาน และถ้าตั้งเกณฑ์ไวเกินไป ทีมงานจะเลิกสนใจการแจ้งเตือน บทความนี้เสนอวิธีเชื่อมความสำคัญของสินทรัพย์ โหมดความเสียหาย baseline เกณฑ์แบบไดนามิก ใบงาน OT security, FAT/SAT และ PoC 90 วันให้เป็นกระบวนการตัดสินใจเดียวสำหรับโรงงานในไทย
CBM คือวงจรงานที่ต้องปิดให้ครบ ไม่ใช่โครงการวัดค่า
ISO 17359:2018 ให้ขั้นตอนทั่วไปสำหรับการจัดทำโปรแกรม condition monitoring หน้า ISO ระบุว่าฉบับนี้ได้รับการทบทวนและยืนยันในปี 2023 และยังเป็นฉบับปัจจุบัน มาตรฐานนี้ไม่ใช่ตารางค่าเตือนของเซนเซอร์รุ่นใดรุ่นหนึ่ง ดังนั้นสิ่งที่ควรจัดซื้อไม่ใช่เพียง “เซนเซอร์ 12 ตัว” แต่คือระบบงานที่ตรวจจับความเสียหายซึ่งวัดได้ สนับสนุนการตัดสินใจ สร้างงานซ่อมอย่างปลอดภัย และพิสูจน์ว่าเครื่องกลับสู่สภาพยอมรับได้

| ขั้นตอน | ข้อมูลเข้า | หลักฐานที่ต้องได้ | ผู้รับผิดชอบ |
|---|---|---|---|
| คัดเลือก | ทะเบียนเครื่อง ประวัติหยุด ความสำคัญ | รายการรวมและเหตุผลที่ตัดออก | ผลิต บำรุงรักษา |
| ออกแบบ | FMEA ประวัติซ่อม แบบเครื่อง | แผนที่ failure mode–signal | วิศวกรรม บำรุงรักษา |
| วัด | จุดติดตั้ง หน่วย รอบวัด สถานะเดินเครื่อง | time series ที่ตรวจคุณภาพแล้ว | OT ผู้ขาย |
| วินิจฉัย | baseline เกณฑ์ กฎลดแจ้งซ้ำ | alert พร้อมเหตุผล | ผู้วิเคราะห์ |
| ลงมือ | ลำดับความสำคัญ กำหนดเวลา ความปลอดภัย | ใบงานและเจ้าของงาน | ผู้วางแผน |
| ปิดงาน | รายการซ่อม วัดซ้ำ สาเหตุ | หลักฐานฟื้นตัวและบทเรียน | หัวหน้าบำรุงรักษา |
เกณฑ์ตรวจรับ PoC ต้องเป็นหลักฐานว่าวงจรนี้ทำงานจริง ไม่ใช่เพียงหน้าจอสวยงาม
แยกความสำคัญของเครื่องออกจากความสามารถในการตรวจจับ
Criticality บอกผลกระทบเมื่อเครื่องเสีย ส่วน detectability บอกว่าจะมีสัญญาณทางกายภาพให้เซนเซอร์ที่เลือกเห็นหรือไม่ เครื่องที่สำคัญมากแต่หยุดเพราะ PLC วัตถุดิบติด หรือขั้นตอนคน อาจไม่ได้ประโยชน์จาก vibration monitoring เพียงอย่างเดียว
| กลุ่ม | ผลกระทบ | ตรวจด้วยสภาพได้ | วิธีใช้ใน PoC |
|---|---|---|---|
| A | สูง | สูง | ทำก่อน เชื่อมอะไหล่และประวัติงาน |
| B | สูง | ต่ำ/ยังไม่ทราบ | วิเคราะห์กลไกเสียก่อนเลือกสัญญาณ |
| C | ปานกลาง | สูง | เหมาะสำหรับเรียนรู้และปรับเกณฑ์ |
| D | ต่ำ | ต่ำ | ตัดออกและคงการตรวจตามรอบ |
คะแนนควรรวมความปลอดภัย คุณภาพ สิ่งแวดล้อม ส่งมอบ เครื่องสำรอง เวลาซ่อม และระยะเวลาจัดหาอะไหล่ในไทย ไม่ใช่เฉพาะมูลค่าการผลิตที่เสียไป จากนั้นจึงผูก failure mode กับสัญญาณและการกระทำ
| โหมดเสีย | สัญญาณนำ | ข้อมูลประกอบ | การกระทำ | ข้อจำกัด |
|---|---|---|---|---|
| ไม่สมดุล | ค่าที่ความถี่รอบเพิ่ม | รอบและโหลด | ทำความสะอาด/บาลานซ์ | โหลดเปลี่ยนทำให้ค่าเปลี่ยน |
| เพลาไม่ตรง | แนวแกนและ harmonic เปลี่ยน | coupling อุณหภูมิ | ตรวจ alignment | resonance อาจคล้ายกัน |
| หลวม | harmonic และรูปคลื่นผิดรูป | ฐานและประวัติขัน | ตรวจฐาน/นอต | จุดติดเซนเซอร์ไม่ดีให้ผลคล้ายกัน |
| ลูกปืนเสีย | impact ความถี่สูงและ envelope | รอบ ชนิดลูกปืน | ตรวจหล่อลื่น/วางแผนเปลี่ยน | ขึ้นกับ bandwidth และการติดตั้ง |
| ร้อนเกิน | แนวโน้มอุณหภูมิ | อุณหภูมิแวดล้อม โหลด | ตรวจระบายความร้อน | อุณหภูมิอย่างเดียวหาสาเหตุไม่ได้ |
| ไฟฟ้า/ควบคุม | กระแสและ event log | PLC/VFD | วินิจฉัยไฟฟ้า | vibration อาจมองไม่เห็น |
ISO 13379-1:2025 ครอบคลุมแนวคิดร่วม ลักษณะทางเทคนิค และคำแนะนำเลือกวิธีวินิจฉัย แต่ไม่ได้บังคับ AI แบบใด จึงควรถามผู้ขายให้ชัดว่าเห็นความเสียหายอะไร ต้องใช้ input อะไร มีข้อจำกัดอะไร และอธิบายผลอย่างไร
สร้าง baseline ตามสถานะเดินเครื่อง ไม่ใช่จำนวนวันมหัศจรรย์
แผนตัวอย่างนี้ใช้ 28 วันสำหรับ baseline แรก เป็นสมมติฐานวางแผน ไม่ใช่ขั้นต่ำตาม ISO แม้เก็บครบหนึ่งเดือน แต่ถ้ามีเพียงโหลดเดียวก็อาจไม่พอ ควรแยก start-up, steady state, โหลดสูง/ต่ำ เปลี่ยนรุ่น ล้างเครื่อง และ idle เครื่อง variable speed ต้องเทียบในช่วงรอบเดียวกัน ปั๊มควรมี flow หรือ valve position ส่วน compressor ควรแยก load/unload
| หัวข้อ baseline | เงื่อนไขรับ | ตัวอย่างไม่ผ่าน | การแก้ไข |
|---|---|---|---|
| ข้อมูลหาย | ไม่เกินค่าที่ตกลง | เติมช่วง gateway ล่มโดยไม่แจ้ง | แก้สื่อสารและเวลา |
| สถานะเดินเครื่อง | แยกสถานะหลักแล้ว | รวม startup กับ steady | แยกโมเดลตามสถานะ |
| การติดตั้ง | มีทิศ จุด และวิธียึด | ติดบนฝาครอบ | ย้ายจุดและเก็บใหม่ |
| หน่วย/สเกล | ต้นทางตรงกับหน้าจอ | สับสน g กับ mm/s | ตรวจสูตรและ calibration |
| สภาพปกติ | ฝ่ายบำรุงยืนยัน | เรียนเครื่องที่กำลังเสื่อมเป็นปกติ | สร้างใหม่หลังซ่อม |
| เวลา | PLC, gateway, CMMS ตรงกัน | timezone คลาดเคลื่อน | ใช้ NTP และกฎแสดงผลเดียวกัน |
ISO 20816-3:2022 ใช้ประเมิน vibration สำหรับเครื่องจักรอุตสาหกรรมที่อยู่ในขอบเขต คือกำลังมากกว่า 15 kW และความเร็ว 120–30,000 r/min ห้ามนำค่าประเมินไปใช้ทั่วไปกับมอเตอร์เล็ก เครื่องรอบต่ำ ช่วง transient หรือเครื่องนอกขอบเขต ต้องใช้ข้อมูลผู้ผลิต baseline รายเครื่อง และมาตรฐานที่เกี่ยวข้องร่วมกัน อ่านเรื่องขอบเขตการวัดเพิ่มเติมได้ที่คู่มือวินิจฉัยเครื่องด้วยเซนเซอร์สั่นสะเทือน
ทำให้ dynamic threshold และการควบคุม false positive ตรวจรับได้

เกณฑ์ไดนามิกต้องเทียบสิ่งที่เหมือนกัน เช่น รอบ โหลด รุ่นสินค้า หรือโหมดเดินเครื่อง คำว่า “AI ปรับให้อัตโนมัติ” ยังตรวจรับไม่ได้ ต้องระบุช่วงเรียนรู้ เวลาที่ตัดออก ความถี่อัปเดต hard limit ผู้อนุมัติ รุ่นโมเดล และวิธีย้อนกลับ
ควรมีอย่างน้อย warning และ alarm โดย warning เริ่มการตรวจสอบ ส่วน alarm เปลี่ยนแผนซ่อมหรือการตัดสินใจเดินเครื่อง ใช้จำนวนครั้งต่อเนื่อง ระยะเวลา หลายสัญญาณ และสถานะเครื่องร่วมกัน ไม่ควรต่อ analytics alert เข้ากับ emergency stop โดยตรงหากไม่มีการออกแบบ safety แยกต่างหาก
| ตัวชี้วัด | ความหมาย | เป้าตัวอย่าง 90 วัน | ข้อควรระวัง |
|---|---|---|---|
| True positive | แจ้งสภาพที่ต้องดำเนินการจริง | เหตุน้อยอาจคำนวณอัตราไม่ได้ | fault injection เฉพาะที่ปลอดภัย |
| False alert | ตรวจแล้วไม่ต้องทำงาน | ≤0.25 ครั้ง/เครื่อง/สัปดาห์ | ตัวอย่าง ไม่ใช่ benchmark |
| Miss | พบภายหลังว่ามี precursor แต่ไม่แจ้ง | มุ่งหมาย critical miss = 0 | รายงานฐานและช่วงสังเกต |
| เวลารับทราบ | alert ถึงผู้รับผิดชอบเปิดดู | ภายใน 4 ชั่วโมงทำการ | ปรับตามกะ |
| เปลี่ยนเป็นงาน | alert ที่ถูกต้องมีคำตัดสิน | บันทึก 100% | ระบุเหตุผลหากไม่ทำ |
| ปิดงาน | วัดซ้ำหลังซ่อมเสร็จ | ≥90% ตามกำหนด | แยกเหตุงานค้าง |
ตัวเลขเหล่านี้เป็นเกณฑ์วางแผน PoC ไม่ใช่ค่าเฉลี่ยอุตสาหกรรม ทุก alert ควรถูกจัดเป็นเสื่อมจริง สถานะเดินเครื่องเปลี่ยน เซนเซอร์/สื่อสารผิดปกติ งานที่ทราบอยู่แล้ว หรือหลักฐานไม่พอ การเปลี่ยน threshold ต้องมีเหตุผล ค่าเก่า/ใหม่ เครื่องที่กระทบ ผู้อนุมัติ และวันที่ใช้
เปลี่ยน alert เป็นใบงาน และปิดหลังวัดซ้ำ
ข้อความแจ้งควรมีชื่อเครื่อง จุดวัด หน่วย สถานะเดินเครื่อง ความต่างจาก baseline อัตราการเปลี่ยน failure mode ที่สงสัย ขั้นตอนตรวจ ลำดับความสำคัญ เวลา และกราฟ หากความมั่นใจต่ำ ให้เสนอการยืนยันที่ปลอดภัย เช่นวัดด้วยเครื่องพกพาหรือตรวจหล่อลื่น ไม่ใช่สั่งเปลี่ยนทันที
| สถานะ | เจ้าของ | บันทึกบังคับ | เงื่อนไขไปต่อ |
|---|---|---|---|
| ใหม่ | ทีม monitor | เวลา เครื่อง หลักฐาน | ตรวจซ้ำและงานที่วางไว้ |
| กำลังวิเคราะห์ | ผู้วินิจฉัย | waveform สถานะ ข้อมูลหน้างาน | ตัดสินใจว่าจะทำอะไร |
| วางแผนแล้ว | planner | งาน อะไหล่ downtime safety | อนุมัติและพร้อม |
| ทำแล้ว | ช่าง | รายละเอียด รูป ค่าอ่าน | พร้อมวัดซ้ำ |
| ตรวจยืนยัน | ผู้วินิจฉัย | ก่อน/หลัง ประเด็นคงเหลือ | กลับปกติหรือทำซ้ำ |
| ปิด | หัวหน้า | สาเหตุ บทเรียน อัปเดตทะเบียน | หลักฐานครบ |
ใช้ alert ID เดียวกันใน CMMS/ERP แม้ PoC จะเชื่อมด้วย CSV ก็ได้ การซ่อมไม่ใช่จุดจบ ต้องวัดซ้ำในสภาพเปรียบเทียบได้และยืนยันว่าค่ากลับมา ข้อมูลก่อน/หลังคือ labeled data ที่มีคุณค่า ดูความต่างเชิงปฏิบัติได้ที่การบำรุงรักษาเชิงคาดการณ์เทียบกับการป้องกัน
ออกแบบ OT security ด้วย segmentation, least privilege และ recovery
NIST SP 800-82 Rev. 3 กล่าวถึงความมั่นคงปลอดภัย OT โดยตระหนักถึงข้อจำกัดด้าน performance, reliability และ safety ควรแยกโซน sensor/gateway, ระบบ monitor และ IT/cloud อนุญาตเฉพาะ traffic ที่จำเป็น บัญชีผู้ขายต้องเป็นรายบุคคล สิทธิน้อย มีวันหมดอายุ การ remote support ต้องขอ อนุมัติ จำกัดเวลา เก็บ log และปิดหลังใช้งาน
| การควบคุม | ตรวจใน FAT | ตรวจใน SAT | หลักฐานระหว่างใช้ |
|---|---|---|---|
| Asset inventory | รุ่น version owner | ตรงกับของจริง | change history |
| Network flow | port และทิศทาง | ทดสอบ allow/deny | firewall review |
| Account | สิทธิและหมดอายุ | login/disable | ทบทวนเป็นระยะ |
| เวลา | แบบ NTP | PLC/GW/cloud ตรง | drift monitoring |
| Backup | ขอบเขต รอบ การป้องกัน | สร้างได้จริง | test record |
| Restore | ขั้นตอนและเจ้าของ | กู้ค่าตัวอย่าง | recovery exercise |
NIST SP 1339 เผยแพร่เดือนมิถุนายน 2026 ระบุให้ backup เชื่อมกับ change management สร้างและทดสอบสม่ำเสมอ และทบทวนใน recovery exercise สำหรับ CBM ให้ครอบคลุมค่า gateway, sensor mapping, threshold, model version, dashboard, integration และประวัติงาน การมีไฟล์ไม่เท่ากับกู้คืนได้ ต้อง restore แล้วเทียบ tag หน่วย threshold และเวลา
ใช้ FAT/SAT ตรวจฟังก์ชัน ข้อมูล workflow และการกู้คืน
FAT ใช้ input จำลองก่อนติดตั้ง ส่วน SAT ใช้เซนเซอร์ เครือข่าย สถานะจริง และผู้ใช้จริง การที่ dashboard เปิดได้ยังไม่พอ
| ด้านทดสอบ | ตัวอย่าง FAT | ตัวอย่าง SAT | หลักฐาน |
|---|---|---|---|
| Function | input หน่วย warning/alarm | สัญญาณและ notification จริง | test case, screen, log |
| Data quality | missing/range/time fault | ตัดและคืนสื่อสาร | missing-rate report |
| Diagnosis | waveform และ state จำลอง | ค่าปกติ/เหตุที่รู้ | expected vs actual |
| Workflow | alert approval job ID | ครบหนึ่งรอบหน้างาน | ใบงานและการปิด |
| Security | deny และ audit | firewall/remote session | access record |
| Recovery | สร้าง backup | restore ตัวอย่าง | เวลาและ checklist |
| เอกสาร/อบรม | procedure/register | ทดสอบปฏิบัติ | version/attendance |
เขียนผลที่คาดก่อนทดสอบ เช่น ใน state A เมื่อ signal X เข้าเงื่อนไข Y จำนวน Z ครั้ง ให้ส่ง warning ไป role P ลดแจ้งซ้ำ N นาที และเก็บ audit log ประเด็นใหญ่เรื่องข้อมูลหาย สิทธิเกิน restore ไม่ได้ หรือ workflow ปิดไม่ได้ ต้อง hold acceptance
PoC 90 วันผ่านสาม decision gate

90 วันเป็นตัวอย่างแผน ไม่ใช่มาตรฐานตลาดหรือการรับประกัน ความเสียหายจริงอาจเกิดน้อยเกินไป จึงต้องประเมินคุณภาพข้อมูล การ replay เหตุเดิม ภาระ alert การปิดงาน recovery และทักษะผู้ใช้ร่วมกัน
| ช่วง | งานหลัก | คำถามที่ gate | สิ่งส่งมอบ |
|---|---|---|---|
| วัน 1–15 | ทะเบียน criticality ประวัติ FMEA สำรวจ network | failure ที่ต้องการวัดได้ไหม | 12 assets และ failure-signal map |
| วัน 16–30 | FAT ติดตั้ง SAT ตรวจ security และ notification | ติดตั้งอย่างปลอดภัยและได้ข้อมูลน่าเชื่อถือไหม | FAT/SAT, drawing, flow matrix |
| วัน 31–45 | เก็บ baseline ตามสถานะ ส่วนที่ 1 | แยกสถานะเดินเครื่องหลักได้ไหม | รายงานคุณภาพแรก state tag และ exclusions |
| วัน 46–60 | เก็บให้ครบและอนุมัติ baseline 28 วัน | normal เปรียบเทียบและอนุมัติได้ไหม | baseline 28 วันที่อนุมัติและ initial warning |
| วัน 61–75 | review false alert งาน และการเปลี่ยน | ทีมรับภาระได้ไหม | change log และ closure |
| วัน 76–90 | recovery drill skill test final review | scale, modify หรือ stop | acceptance และแผนถัดไป |
ภายในวัน 30 ต้องจบ FAT การติดตั้ง และ SAT หากข้อมูลหาย เวลา หน่วย หรือ notification ยังไม่ผ่าน ห้ามเริ่มเก็บ baseline ในวัน 31 ช่วงตัวอย่าง 28 วันคือวัน 31–58 และใช้วัน 59–60 ทบทวนและอนุมัติ state tag, exclusions และคุณภาพ Scale เมื่อวงจรปิดได้ ความเสี่ยงใหญ่ถูกแก้ และเครื่องถัดไปมี failure mode ที่วิธีนี้ครอบคลุม Modify เมื่อสมมติฐานคุณค่ายังอยู่แต่ต้องแก้ data/state/workflow Stop เมื่อความเสียหายหลักมองไม่เห็น ปิดงานไม่ได้ หรือ security/recovery ไม่ผ่าน การหยุดด้วยหลักฐานก็เป็นผล PoC ที่มีค่า
คำนวณเศรษฐศาสตร์แบบระมัดระวัง
ตัวเลขต่อไปนี้คือสถานการณ์วางแผนสมมติ 12 assets ไม่ใช่ราคาตลาด ผลลูกค้าจริง หรือคำมั่น
| ต้นทุน | สมมติฐาน (THB) | การคำนวณ |
|---|---|---|
| Sensor, gateway, software | 420,000 | กรอบงบสมมติ |
| Integration, training, FAT/SAT | 280,000 | กรอบงานสมมติ |
| Contingency | 105,000 | (420,000 + 280,000) × 15% |
| Internal review | 93,600 | 6 ชม./สัปดาห์ × 13 × 1,200 |
| รวม 90 วัน | 898,600 | ผลรวมข้างต้น |
ถ้าป้องกันเหตุได้ 2 ครั้ง ครั้งละ 5 ชั่วโมง และสมมติผลกระทบ 70,000 THB/ชั่วโมง ผลหลีกเลี่ยงคือ 2 × 5 × 70,000 = 700,000 THB ถ้าลดการเปลี่ยนตามรอบที่ไม่จำเป็น 12 งาน งานละ 12,000 THB จะเพิ่ม 144,000 THB ประโยชน์รวมสมมติ 844,000 THB และ 844,000 − 898,600 = ติดลบ 54,600 THB ณ วัน 90 ไม่ควรบังคับให้ ROI เป็นบวก PoC ซื้อหลักฐานว่าตรวจเห็น จัดการ alert ปิดงาน และกู้ระบบได้ด้วย
| ประเด็นตัดสิน | ขยายผล | ปรับแก้และดำเนินต่อ | หยุดหรือใช้วิธีอื่น |
|---|---|---|---|
| ความสอดคล้องของ failure mode | ความเสียหายหลักมีสัญญาณนำที่สังเกตได้ | ต้องเพิ่มสัญญาณให้บางขอบเขต | ความเสียหายหลักอยู่นอกปรากฏการณ์ที่วัด |
| คุณภาพข้อมูล | เสถียรและทำซ้ำได้ | แก้สื่อสารหรือ state tag | ไม่สามารถรักษาความน่าเชื่อถือระหว่างใช้งาน |
| ภาระทีมงาน | จัดการ alert ได้ภายใน SLA | ออกแบบ suppression หรือ owner ใหม่ | งานค้างเกินกำหนดอย่างต่อเนื่อง |
| Security และ recovery | ผ่านข้อกำหนด | เหลือ corrective action จำกัด | ยังมีความเสี่ยงสำคัญที่ไม่แก้ |
| เศรษฐศาสตร์ | ยังสมเหตุผลเมื่อเปลี่ยนสมมติฐาน | ขยายช่วงสังเกตก่อนลงทุน | มีทางเลือกอื่นที่ดีกว่าอย่างชัดเจน |
ประกาศทางการ BOI/OSOS สำหรับครึ่งแรกปี 2026 ระบุคำขอด้านเครื่องจักร ระบบอัตโนมัติ และหุ่นยนต์ประมาณ 13,100 ล้านบาท ใน 82 โครงการ และมาตรการ Smart and Sustainable Industry จำนวน 132 คำขอ มูลค่าประมาณ 17,200 ล้านบาท ตัวเลขนี้เป็นบริบทการลงทุนเท่านั้น คุณสมบัติและการอนุมัติขึ้นกับแต่ละโครงการ ต้องตรวจสอบเป็นรายกรณีและห้ามตั้งงบสิทธิประโยชน์ก่อนอนุมัติ
10 คำถามสำหรับผู้ขายระบบ CBM
- ระบบครอบคลุม failure mode ใด และไม่ครอบคลุมอะไร?
- มีสมมติฐานด้านสัญญาณ จุดติดตั้ง sampling และสถานะเดินเครื่องอย่างไร?
- ISO 20816-3 ใช้กับเครื่องใดและภายในขอบเขตใดอย่างชัดเจน?
- กฎสำหรับ baseline ช่วงที่ตัดออก และการเรียนรู้ใหม่คืออะไร?
- ใครอนุมัติการเปลี่ยน dynamic threshold และย้อนกลับรุ่นเดิมได้หรือไม่?
- รายงาน false alert, miss และกรณีหลักฐานไม่เพียงพออย่างไร?
- ติดตาม alert ไปจนถึง work order ที่ปิดและการวัดซ้ำหลังซ่อมอย่างไร?
- ออกแบบ OT zone, data flow, remote access และระยะเวลาเก็บ log อย่างไร?
- สำรองข้อมูลอะไร และทดสอบ restore อะไรใน FAT/SAT?
- ใช้หลักฐานใดตัดสินใจขยาย ปรับแก้ หรือหยุดหลัง 90 วัน?
คำถามที่พบบ่อย
CBM เหมือน predictive maintenance หรือไม่?
ไม่เหมือนทั้งหมด CBM ใช้สภาพที่วัดได้ตัดสินใจงาน ส่วน predictive อาจคาดการณ์สภาพอนาคตหรือ remaining life ได้ CBM มีคุณค่าได้แม้ไม่มีโมเดลอายุคงเหลือ หากการตัดสินใจและการปิดงานควบคุมได้
Maintenance DX ควรเริ่มจากเซนเซอร์ไหม?
ควรเริ่มจากประวัติเหตุ criticality, failure mode และ workflow จากนั้นจึงเลือกสัญญาณและจุดติดตั้ง
ใช้ ISO ตั้ง vibration threshold ของมอเตอร์อย่างเดียวได้ไหม?
ไม่ได้ ISO 20816-3 ใช้ได้กับเครื่องในขอบเขต ต้องรวมจุดติดตั้ง สถานะเดินเครื่อง ข้อมูลผู้ผลิต และ baseline รายเครื่อง
False alert ยอมได้กี่ครั้ง?
ไม่มีเลขเดียว ขึ้นกับ criticality กะ และกำลังตรวจ ตั้งเป้า PoC ล่วงหน้าและวิเคราะห์สาเหตุ ไม่ใช่เพียงปิด alert
ถ้า PoC ไม่มีเครื่องเสียจริงถือว่าล้มเหลวไหม?
ไม่จำเป็น ยังตรวจ data quality, known event, workflow, restore และทักษะได้ แต่ห้ามอ้าง detection rate หรือ savings ที่ไม่เกิดจริง
CBM ได้สิทธิ BOI อัตโนมัติหรือไม่?
ไม่ได้ ตัวเลข BOI เป็นข้อมูลบริบท ต้องยืนยัน eligibility และ approval รายโครงการ
สรุป
CBM ที่ใช้งานได้ต้องเชื่อม criticality กับ failure physics, baseline ตามสถานะ, threshold ที่ควบคุมการเปลี่ยน, alert ที่นำไปสู่ใบงานและการวัดซ้ำ, OT segmentation และ recovery ที่ทดสอบแล้ว FAT/SAT และ PoC 90 วันควรสร้างหลักฐานสำหรับสามคำตอบที่ถูกต้องได้เสมอ: ขยาย แก้ไข หรือหยุด
TOMAS TECH สามารถช่วยโรงงานในไทยและอาเซียนจัดกลุ่มเครื่อง ทำ failure-signal map วาง FAT/SAT และเกณฑ์ตรวจรับ 90 วันได้ตั้งแต่ก่อนเลือกผลิตภัณฑ์ หากต้องการทบทวนแผน สามารถส่งประวัติหยุดและข้อจำกัดเครือข่ายผ่านหน้าติดต่อ