การซ่อมบำรุงเชิงพยากรณ์ของเครื่องบินและรถไฟ: AI รู้ได้อย่างไรก่อนที่ชิ้นส่วนจะพัง

ตีหนึ่งสี่สิบนาที ในโรงเก็บเครื่องบินข้างสนามบินเถาหยวน ไม่มีใครอยากได้ยินคำว่า "ถอดออกมาดูก่อน"

ตีหนึ่งสี่สิบนาที โรงเก็บเครื่องบินแห่งหนึ่งทางใต้ของสนามบินเถาหยวนยังเปิดไฟอยู่ เครื่องบินลำตัวแคบที่ต้องบินเช้าวันรุ่งขึ้นจอดอยู่ข้างใน วิศวกรจ้องกราฟการสั่นสะเทือนที่กระเพื่อมอยู่บนจอ ตัวเลขยังอยู่ในเกณฑ์ที่ยอมรับได้ แต่แนวโน้มไม่เหมือนเมื่อสามสัปดาห์ก่อน

การตัดสินใจถัดไปเป็นเรื่องจริงมาก จะถอดออกมาดูตอนนี้ไหม ถ้าถอด เครื่องลำนี้บินเช้าพรุ่งนี้ไม่ได้ ต้องจัดตารางเที่ยวบินใหม่ ต้องปลอบผู้โดยสาร ต้นทุนเริ่มต้นที่หลักหกหลัก ถ้าไม่ถอด แล้วเกิดเรื่องขึ้นจริง ราคาที่ต้องจ่ายไม่ได้อยู่ในระดับเดียวกันเลย

นี่คือปัญหาที่การซ่อมบำรุงเชิงพยากรณ์ต้องการแก้จริง ๆ มันไม่ใช่ "AI ช่วยคุณดูแดชบอร์ด" แต่คือ "ภายใต้ข้อมูลที่ไม่เพียงพอ จะเปลี่ยนการพนันหนึ่งครั้งให้กลายเป็นการตัดสินใจที่มีช่วงความเชื่อมั่นได้อย่างไร" เครื่องบินเป็นเช่นนี้ แคร่รถไฟความเร็วสูงก็เป็นเช่นนี้ เครื่องจักรในโรงงานผลิตเวเฟอร์ก็เช่นกัน

ภูมิหลังของเหตุการณ์

เรื่องการซ่อมบำรุงในเชิงวิศวกรรม แบ่งได้คร่าว ๆ สามแนวทาง

แนวทางแรกคือ พังแล้วค่อยซ่อม (reactive) ต้นทุนต่ำที่สุดแต่ความเสี่ยงสูงที่สุด เหมาะกับของที่พังแล้วไม่ทำให้ใครเสียชีวิตเท่านั้น แนวทางที่สองคือ ป้องกันตามรอบเวลา (time-based) อย่าง A check, C check ที่วงการบินทำมานาน และรอบตรวจซ่อมประจำของระบบราง ล้วนอยู่ในกลุ่มนี้ ใช้ชั่วโมงบิน จำนวนครั้งขึ้นลง หรือระยะทางวิ่งเป็นเงื่อนไขกระตุ้น แนวทางที่สามคือ การซ่อมบำรุงตามสภาพ (condition-based) และการซ่อมบำรุงเชิงพยากรณ์ (predictive) ซึ่งอาศัยข้อมูลจากเซนเซอร์ตัดสินว่า "ชิ้นส่วนนี้สุขภาพเป็นอย่างไรในตอนนี้ และน่าจะทนได้อีกนานแค่ไหน"

แนวทางที่สองปลอดภัย แต่สิ้นเปลืองอย่างน่าตกใจ ตรรกะของการเปลี่ยนชิ้นส่วนตามรอบคือ "สมมติว่าทุกชิ้นส่วนถูกใช้งานหนักเท่ากัน" แต่ในความเป็นจริง ตลับลูกปืนรุ่นเดียวกันที่ติดตั้งในรถคนละเส้นทาง คนละสภาพอากาศ คนละพฤติกรรมการขับ อายุการใช้งานต่างกันได้หลายเท่า เปลี่ยนเร็วเกินไป เท่ากับทิ้งชิ้นส่วนที่ยังใช้ได้ เปลี่ยนช้าเกินไป ก็คือฉากที่ไม่มีใครอยากเจอ

สิ่งที่ผลักดันคลื่นการเปลี่ยนแปลงระลอกนี้คือปริมาณข้อมูล แพลตฟอร์ม AVIATAR ของ Lufthansa Technik ระบุในเอกสารทางการว่า "เครื่องบินรุ่นใหม่ล่าสุดสร้างข้อมูลมากกว่ารุ่นก่อนหน้าถึง 50 เท่า" ส่วนตัวแพลตฟอร์มเองวางตำแหน่งไว้ว่า "สนับสนุนให้ลูกค้าบริหารฝูงบินที่ซับซ้อนแบบเรียลไทม์ และทำนายความน่าจะเป็นที่ชิ้นส่วนเดี่ยว ๆ จะเสียหาย" ประโยคนี้ควรค่าแก่การขบคิด ประเด็นไม่ได้อยู่ที่แดชบอร์ดของฝูงบิน แต่อยู่ที่ความน่าจะเป็นของการเสียหายในระดับ "single component"

ฝั่งเครื่องยนต์ก็เช่นกัน เมื่อ Rolls-Royce อธิบายเรื่อง digital twin เขียนไว้ตรงมาก แฝดดิจิทัลตัวนี้ "จะทำงานในโลกเสมือนในแบบเดียวกับเครื่องยนต์จริงที่ติดอยู่ใต้ปีก เพื่อประเมินสภาพการทำงานของเครื่องยนต์ และทำนายว่าเมื่อไรมันอาจต้องการการซ่อมบำรุง" ซึ่งเป็นส่วนหนึ่งของวิสัยทัศน์ IntelligentEngine ของบริษัท

ฝั่งกฎระเบียบเคลื่อนไหวเร็วกว่าที่คนส่วนใหญ่คิด องค์การความปลอดภัยการบินยุโรป (EASA) เผยแพร่ AI Roadmap 1.0 เมื่อวันที่ 7 กุมภาพันธ์ 2020 เผยแพร่เวอร์ชัน 2.0 เมื่อ 10 พฤษภาคม 2023 และเผยแพร่ AI Concept Paper Issue 2 เมื่อ 6 มีนาคม 2024 ให้แนวทางสำหรับการประยุกต์ใช้ machine learning ระดับ Level 1 และ Level 2 นอกจากนี้ EASA ยังดำเนินโครงการวิจัย MLEAP (Machine Learning Application Approval) เพื่อจัดการปัญหาว่าระบบ machine learning ควรถูกตรวจสอบและอนุมัติอย่างไร EASA เองระบุว่าโรดแมปฉบับนี้เป็น "living document" ที่ปรับปรุงปีละครั้ง โดยมีหลักการหลักคือ "a human-centric approach to AI in aviation"

ไต้หวันไม่ใช่ผู้สังเกตการณ์ข้างสนามของห่วงโซ่อุปทานนี้ Evergreen Aviation Technologies (EGAT) ก่อตั้งในปี 1998 โดยการร่วมทุนระหว่าง EVA Air กับ GE ตั้งฐานอยู่ที่สนามบินนานาชาติเถาหยวน เว็บไซต์ทางการระบุว่าถือใบรับรองศูนย์ซ่อม Part-145 ของ FAA, EASA และ JCAB ของญี่ปุ่น และให้บริการสายการบินกว่า 40 แห่ง ธุรกิจซ่อมบำรุงนี้ ไต้หวันมีผลงานจริง

ประเด็นสำคัญครั้งนี้

• แหล่งที่มาของสัญญาณสำคัญกว่าโมเดล: ฝั่งการบินมีข้อความสถานะเครื่องยนต์ที่ส่งผ่าน ACARS และข้อมูลการบิน QAR ส่วนฝั่งอุตสาหกรรมและระบบรางส่วนใหญ่พึ่งเซนเซอร์วัดการสั่นสะเทือนและอุณหภูมิที่ติดตั้งเพิ่ม Augury เดินเส้นทาง "เซนเซอร์ไร้สายของตัวเอง บวกกับ machine learning" ส่วน TRACTIAN ก็มัดเซนเซอร์การสั่นและอุณหภูมิแบบ IoT เข้ากับการตรวจจับความผิดปกติด้วย AI ขายไปด้วยกัน
• ทำการตรวจจับความผิดปกติก่อน วางการทำนายอายุการใช้งานไว้ทีหลัง: ทำให้ได้ก่อนว่า "เครื่องนี้ต่างจากตัวมันเองเมื่อเดือนก่อน" แล้วค่อยพูดถึงอายุการใช้งานที่เหลือ (RUL) โครงการที่ล้มเหลวส่วนใหญ่ทำสลับลำดับ
• ทำนายเสร็จต้องจัดเข้าใบสั่งงานได้ด้วย: การเตือนล่วงหน้าที่ไม่เชื่อมเข้ากับการจัดตารางซ่อม สต็อกอะไหล่ และการจัดสรรกำลังคน มีมูลค่าเท่ากับศูนย์ แพลตฟอร์มระดับองค์กรอย่าง C3 AI ที่เน้นแอปสำเร็จรูป ก็มีจุดสำคัญอยู่ที่การจัดตารางและการปรับสต็อกให้เหมาะสมในครึ่งหลัง
• การตรวจสอบด้วยภาพกำลังแพร่หลาย: เรขาคณิตของราง สายไฟฟ้าเหนือหัว รอยเสียหายบนผิวลำตัวเครื่อง ใช้กล้องบวกโมเดลสแกนผ่านครั้งเดียว เร็วกว่าให้คนปีนขึ้นไปดูมาก และปลอดภัยกว่ามาก
• กฎระเบียบไม่อนุญาตให้คุณแก้รอบซ่อมโดยตรง: โมเดลบอกว่าเลื่อนเปลี่ยนชิ้นส่วนได้ ไม่ได้แปลว่าคุณเลื่อนได้ การเปลี่ยนแผนซ่อมต้องผ่านกระบวนการของหน่วยงานความสมควรเดินอากาศ นี่คือความแตกต่างที่ใหญ่ที่สุดระหว่างการบินกับระบบราง เทียบกับภาคผลิตทั่วไป

วิเคราะห์ผลกระทบต่อตลาด

ผู้ใช้ในไต้หวัน

สิ่งที่คุณรู้สึกได้คืออัตราตรงเวลาและการยกเลิกกะทันหัน ฝูงบินที่ทำการซ่อมบำรุงเชิงพยากรณ์ได้ดี จะย้ายปัญหาที่ "เดิมต้องจัดการฉุกเฉินที่สนามบินปลายทาง" มาทำให้เสร็จในช่วงซ่อมบำรุงที่ฐานตอนกลางคืนล่วงหน้า ผู้โดยสารจึงเห็นการ "ล่าช้าเพราะขัดข้องทางกลไก" น้อยลงหนึ่งครั้ง

แต่ก็อย่าคาดหวังมากเกินไป การเตือนซ่อมบำรุงจัดการได้แค่ "ความเสื่อมสภาพแบบค่อยเป็นค่อยไปที่มีสัญญาณ" เท่านั้น ทำอะไรไม่ได้กับวัตถุแปลกปลอมกระแทกกะทันหัน นกชน หรือสภาพอากาศ ในบรรดาสาเหตุของความล่าช้า ปัญหาทางกลไกมักไม่ใช่ตัวใหญ่ที่สุด

การใช้งานในองค์กร

ตรงนี้มีจุดสำคัญที่ภาคผลิตของไต้หวันมักมองข้าม ระเบียบวิธีการซ่อมบำรุงเชิงพยากรณ์ของการบินและระบบราง แทบเป็นชุดเดียวกันกับอุปกรณ์ในโรงงาน มอเตอร์ ปั๊ม คอมเพรสเซอร์ พัดลม เพลาหลัก สเปกตรัมการสั่น แนวโน้มอุณหภูมิที่สูงขึ้น ลักษณะกระแสไฟฟ้า เปลี่ยนสนามก็ตรรกะเดิม

คำแนะนำของผมคือทำย้อนกลับ อย่าเพิ่งรีบซื้อโมเดล ใช้เวลาสามเดือนทำสามเรื่องนี้ให้ดีก่อน หนึ่ง ทำใบสั่งงานซ่อมให้เป็นดิจิทัล และต้องบันทึก "เปลี่ยนอะไร ทำไมถึงเปลี่ยน อาการตอนนั้นเป็นอย่างไร" สอง ติดเซนเซอร์บนอุปกรณ์ที่พังจริงและพังแล้วเจ็บจริง ไม่ใช่ติดให้มากที่สุด สาม นิยามให้ชัดว่าต้นทุนจริงของการหยุดเครื่องนอกแผนหนึ่งครั้งคือเท่าไร ถ้าคำนวณตัวเลขนี้ไม่ได้ ผลตอบแทนการลงทุนที่ตามมาก็เป็นแค่ความรู้สึกทั้งนั้น

นักพัฒนา

นี่เป็นปัญหาที่ไม่ Kaggle เอามาก ๆ ขอพูดถึงหลุมพรางเชิงปฏิบัติสักหน่อย

ข้อมูลไม่สมดุลอย่างสุดขั้วและถูกตัดปลาย (censored) อุปกรณ์ส่วนใหญ่ยังไม่พังจนจบช่วงสังเกต ในทางสถิติเรียกว่าข้อมูลแบบ right-censored โยนเข้า binary classifier ตรง ๆ จะได้โมเดลที่ดูแม่นมากแต่ใช้งานจริงไม่ได้ เครื่องมือเก่าอย่าง survival analysis และการแจกแจง Weibull กลับใช้ได้ดีกว่า deep learning ในที่นี้

ป้ายกำกับมาจากใบสั่งงานซ่อม และใบสั่งงานคนเป็นคนเขียน ความเสียหายเดียวกันมีวิธีเขียนห้าแบบ timestamp อาจเป็นเวลาที่ลงทะเบียนไม่ใช่เวลาที่เกิดเหตุ การทำ feature engineering ก็กินความรู้เฉพาะทาง สัญญาณการสั่นต้องทำ FFT และ envelope demodulation หาสิ่งที่มองหาคือ sideband ของความถี่จำเพาะ ไม่ใช่โยนคลื่นดิบเข้า network ก็จบ

ตัวชี้วัดการประเมินยิ่งต้องระวัง ความแม่นยำ (accuracy) ไม่มีความหมายเลย สิ่งที่ต้องดูคือ PR-AUC เวลาเตือนล่วงหน้าเฉลี่ย และค่าใช้จ่ายของการเตือนผิดหนึ่งครั้ง ในวงการบิน การถอดตรวจโดยไม่จำเป็นครั้งหนึ่งอาจแพงกว่าเงินที่โมเดลประหยัดได้ทั้งปี สุดท้ายคือการนำไปใช้งาน เครือข่ายหน้างานแย่ กำลังประมวลผลจำกัด โมเดลส่วนใหญ่จึงต้องรันที่ edge และต้องอธิบายได้ว่าทำไมถึงส่งสัญญาณเตือน เพราะฝ่ายตรวจสอบจะถาม อยากฝึกพื้นฐานเรื่อง prompt และการจัดระเบียบข้อมูล ลองเปิด คลังพรอมป์ และ คลังงาน บนเว็บไซต์ดูก่อนได้

แนวโน้มการพัฒนาในอนาคต

สามปีข้างหน้า ผมมองบวกกับสามทิศทาง

หนึ่ง foundation model สำหรับ time series และสัญญาณการสั่น ปัจจุบันโซลูชันส่วนใหญ่ยังฝึกหนึ่งโมเดลต่อหนึ่งอุปกรณ์ ความสามารถถ่ายโอนข้ามอุปกรณ์แย่มาก ถ้าโมเดลที่ pretrain แล้วทำให้ปริมาณข้อมูลที่อุปกรณ์ใหม่ต้องใช้ในการเริ่มต้นแบบเย็นลดลงได้หนึ่ง order of magnitude กำแพงการนำไปใช้จะเปลี่ยนไปทั้งหมด

สอง กฎระเบียบค่อย ๆ ผ่อนคลาย EASA เขียนการประยุกต์ machine learning ระดับ Level 1 และ Level 2 เข้าไปในแนวทางแล้ว โรดแมปปรับปรุงทุกปี เมื่อ "การตัดสินใจซ่อมบำรุงที่ช่วยโดย AI" มีเส้นทางการตรวจสอบที่ชัดเจน ผู้ประกอบการ MRO จึงจะกล้าเขียนมันเข้าไปในแผนซ่อมจริง ๆ

สาม โอกาสของไต้หวันอยู่ที่ชั้นกลาง เรามีผลงาน MRO มีแรงกดดันเรื่องอัตราการใช้งานอุปกรณ์เซมิคอนดักเตอร์ และมีห่วงโซ่อุปทานที่ทำเซนเซอร์และระบบควบคุมอุตสาหกรรม สิ่งที่ขาดแคลนจริง ๆ ไม่ใช่โมเดล แต่คือคนที่ "เข้าใจทั้งอุปกรณ์และข้อมูล" คนแบบนี้ตอนนี้ในไต้หวันยังไม่พอ และเงินเดือนก็ยังไม่สะท้อนความหายาก

บทสรุปและความเห็นจาก TheAI Academy

เวลาผมดูโครงการซ่อมบำรุงเชิงพยากรณ์ ผมตัดสินความสำเร็จหรือล้มเหลวด้วยคำถามเดียว การเตือนที่ส่งออกมานี้ ใครจะทำอะไรต่อ ตอบไม่ได้ ต่อให้ทำนายแม่นแค่ไหนก็เปล่าประโยชน์

จุดที่น่าหลงใหลที่สุดของสาขานี้คือ มันบังคับให้คุณเผชิญหน้ากับส่วนที่ไม่โรแมนติกที่สุดใน machine learning ข้อมูลสกปรก ตัวอย่างบวกมีน้อย โมเดลต้องอธิบายได้ ผิดแล้วต้องรับผิดชอบ มันจะไม่มีเสียงฮือฮาในงาน demo day แต่มันจะสะท้อนตรง ๆ ว่าเครื่องบินจะขึ้นตรงเวลาได้ไหม ขบวนรถไฟจะหยุดในอุโมงค์หรือเปล่า

มูลค่าของการซ่อมบำรุงเชิงพยากรณ์ไม่ได้อยู่ที่การพยากรณ์ แต่อยู่ที่มันเปลี่ยนการซ่อมจาก "การพนัน" ให้เป็น "การคำนวณ"

คำแนะนำที่เป็นรูปธรรมสำหรับผู้อ่าน ถ้าคุณเป็นวิศวกร เติมความรู้เรื่อง survival analysis การประมวลผลสัญญาณ และการทำความสะอาดข้อมูลใบสั่งงานให้ครบ มูลค่าในตลาดของสามอย่างนี้สูงกว่าการไปทำแอป LLM เพิ่มอีกตัวมาก ถ้าคุณเป็นผู้บริหารภาคผลิต เดือนนี้ไปยืนยันเรื่องหนึ่งเลย ในใบสั่งงานซ่อมของคุณ มีการบันทึก "อาการ" ไหม ถ้าไม่มี การจัดซื้อระบบซ่อมบำรุงเชิงพยากรณ์ใด ๆ ก็เร็วเกินไปที่จะพูดถึง

แหล่งข้อมูล

• EASA – Artificial Intelligence (AI Roadmap และ Concept Paper)
• Lufthansa Technik – AVIATAR
• Rolls-Royce – How Digital Twin technology can enhance Aviation