SlideShare a Scribd company logo
𝑝𝑟𝑒𝑐𝑖𝑠𝑖𝑜𝑛 =
𝑓𝑎𝑖𝑙𝑢𝑟𝑒𝑠 𝑐𝑜𝑟𝑟𝑒𝑐𝑡𝑙𝑦 𝑖𝑑𝑒𝑛𝑡𝑖𝑓𝑖𝑒𝑑
𝑓𝑎𝑖𝑙𝑢𝑟𝑒𝑠 𝑐𝑜𝑟𝑟𝑒𝑐𝑡𝑙𝑦 𝑖𝑑𝑒𝑛𝑡𝑖𝑓𝑖𝑒𝑑+ℎ𝑒𝑎𝑙𝑡ℎ𝑦 𝑒𝑛𝑔𝑖𝑛𝑒𝑠 𝑖𝑛𝑐𝑜𝑟𝑟𝑒𝑐𝑡𝑙𝑦 𝑙𝑎𝑏𝑒𝑙𝑒𝑑 𝑎𝑠 𝑓𝑎𝑖𝑙𝑒𝑑
𝑝𝑟𝑒𝑐𝑖𝑠𝑖𝑜𝑛 =
𝑡𝑟𝑢𝑒 𝑝𝑜𝑠𝑠𝑖𝑡𝑖𝑣𝑒
𝑡𝑟𝑢𝑒 𝑝𝑜𝑠𝑠𝑖𝑡𝑖𝑣𝑒+𝑓𝑎𝑙𝑠𝑒 𝑝𝑜𝑠𝑠𝑖𝑡𝑖𝑣𝑒
𝑟𝑒𝑐𝑎𝑙𝑙 =
𝑡𝑟𝑢𝑒 𝑝𝑜𝑠𝑠𝑖𝑡𝑖𝑣𝑒
𝑡𝑟𝑢𝑒 𝑝𝑜𝑠𝑠𝑖𝑡𝑖𝑣𝑒 + 𝑓𝑎𝑙𝑠𝑒 𝑛𝑒𝑔𝑎𝑡𝑖𝑣𝑒
𝑟𝑒𝑐𝑎𝑙𝑙 =
𝑓𝑎𝑖𝑙𝑢𝑟𝑒𝑠 𝑐𝑜𝑟𝑟𝑒𝑐𝑡𝑙𝑦 𝑖𝑑𝑒𝑛𝑡𝑖𝑓𝑖𝑒𝑑
𝑓𝑎𝑖𝑙𝑢𝑟𝑒𝑠 𝑐𝑜𝑟𝑟𝑒𝑐𝑡𝑙𝑦 𝑖𝑑𝑒𝑛𝑡𝑖𝑓𝑖𝑒𝑑 + 𝑓𝑎𝑢𝑙𝑡𝑦 𝑒𝑛𝑔𝑖𝑛𝑒𝑠 𝑖𝑛𝑐𝑜𝑟𝑟𝑒𝑐𝑡𝑙𝑦 𝑙𝑒𝑏𝑙𝑒𝑑 𝑎𝑠 ℎ𝑒𝑎𝑙𝑡ℎ𝑦
𝐹1 𝑠𝑐𝑜𝑟𝑒 = 2 ∗
𝑝𝑟𝑒𝑐𝑖𝑠𝑖𝑜𝑛 ∗ 𝑟𝑒𝑐𝑎𝑙𝑙
𝑝𝑟𝑒𝑐𝑖𝑠𝑖𝑜𝑛 + 𝑟𝑒𝑐𝑎𝑙𝑙
Predictive Maintenance
Predictive Maintenance
Predictive Maintenance
Predictive Maintenance
Predictive Maintenance
Predictive Maintenance
Predictive Maintenance
Predictive Maintenance
Predictive Maintenance
Predictive Maintenance
Predictive Maintenance
Predictive Maintenance
Predictive Maintenance
Predictive Maintenance
Predictive Maintenance
Predictive Maintenance
Predictive Maintenance
Predictive Maintenance
Predictive Maintenance
Predictive Maintenance
Predictive Maintenance

More Related Content

More from Software Guru

Building bias-aware environments
Building bias-aware environmentsBuilding bias-aware environments
Building bias-aware environments
Software Guru
 
El secreto para ser un desarrollador Senior
El secreto para ser un desarrollador SeniorEl secreto para ser un desarrollador Senior
El secreto para ser un desarrollador Senior
Software Guru
 
Cómo encontrar el trabajo remoto ideal
Cómo encontrar el trabajo remoto idealCómo encontrar el trabajo remoto ideal
Cómo encontrar el trabajo remoto ideal
Software Guru
 
Automatizando ideas con Apache Airflow
Automatizando ideas con Apache AirflowAutomatizando ideas con Apache Airflow
Automatizando ideas con Apache Airflow
Software Guru
 
How thick data can improve big data analysis for business:
How thick data can improve big data analysis for business:How thick data can improve big data analysis for business:
How thick data can improve big data analysis for business:
Software Guru
 
Introducción al machine learning
Introducción al machine learningIntroducción al machine learning
Introducción al machine learning
Software Guru
 
Democratizando el uso de CoDi
Democratizando el uso de CoDiDemocratizando el uso de CoDi
Democratizando el uso de CoDi
Software Guru
 
Gestionando la felicidad de los equipos con Management 3.0
Gestionando la felicidad de los equipos con Management 3.0Gestionando la felicidad de los equipos con Management 3.0
Gestionando la felicidad de los equipos con Management 3.0
Software Guru
 
Taller: Creación de Componentes Web re-usables con StencilJS
Taller: Creación de Componentes Web re-usables con StencilJSTaller: Creación de Componentes Web re-usables con StencilJS
Taller: Creación de Componentes Web re-usables con StencilJS
Software Guru
 
El camino del full stack developer (o como hacemos en SERTI para que no solo ...
El camino del full stack developer (o como hacemos en SERTI para que no solo ...El camino del full stack developer (o como hacemos en SERTI para que no solo ...
El camino del full stack developer (o como hacemos en SERTI para que no solo ...
Software Guru
 
¿Qué significa ser un programador en Bitso?
¿Qué significa ser un programador en Bitso?¿Qué significa ser un programador en Bitso?
¿Qué significa ser un programador en Bitso?
Software Guru
 
Colaboración efectiva entre desarrolladores del cliente y tu equipo.
Colaboración efectiva entre desarrolladores del cliente y tu equipo.Colaboración efectiva entre desarrolladores del cliente y tu equipo.
Colaboración efectiva entre desarrolladores del cliente y tu equipo.
Software Guru
 
Pruebas de integración con Docker en Azure DevOps
Pruebas de integración con Docker en Azure DevOpsPruebas de integración con Docker en Azure DevOps
Pruebas de integración con Docker en Azure DevOps
Software Guru
 
Elixir + Elm: Usando lenguajes funcionales en servicios productivos
Elixir + Elm: Usando lenguajes funcionales en servicios productivosElixir + Elm: Usando lenguajes funcionales en servicios productivos
Elixir + Elm: Usando lenguajes funcionales en servicios productivos
Software Guru
 
Así publicamos las apps de Spotify sin stress
Así publicamos las apps de Spotify sin stressAsí publicamos las apps de Spotify sin stress
Así publicamos las apps de Spotify sin stress
Software Guru
 
Achieving Your Goals: 5 Tips to successfully achieve your goals
Achieving Your Goals: 5 Tips to successfully achieve your goalsAchieving Your Goals: 5 Tips to successfully achieve your goals
Achieving Your Goals: 5 Tips to successfully achieve your goals
Software Guru
 
Acciones de comunidades tech en tiempos del Covid19
Acciones de comunidades tech en tiempos del Covid19Acciones de comunidades tech en tiempos del Covid19
Acciones de comunidades tech en tiempos del Covid19
Software Guru
 
De lo operativo a lo estratégico: un modelo de management de diseño
De lo operativo a lo estratégico: un modelo de management de diseñoDe lo operativo a lo estratégico: un modelo de management de diseño
De lo operativo a lo estratégico: un modelo de management de diseño
Software Guru
 
La importancia de crear User Personas y Escenarios
La importancia de crear User Personas y EscenariosLa importancia de crear User Personas y Escenarios
La importancia de crear User Personas y Escenarios
Software Guru
 
La vida después de la escuela
La vida después de la escuelaLa vida después de la escuela
La vida después de la escuela
Software Guru
 

More from Software Guru (20)

Building bias-aware environments
Building bias-aware environmentsBuilding bias-aware environments
Building bias-aware environments
 
El secreto para ser un desarrollador Senior
El secreto para ser un desarrollador SeniorEl secreto para ser un desarrollador Senior
El secreto para ser un desarrollador Senior
 
Cómo encontrar el trabajo remoto ideal
Cómo encontrar el trabajo remoto idealCómo encontrar el trabajo remoto ideal
Cómo encontrar el trabajo remoto ideal
 
Automatizando ideas con Apache Airflow
Automatizando ideas con Apache AirflowAutomatizando ideas con Apache Airflow
Automatizando ideas con Apache Airflow
 
How thick data can improve big data analysis for business:
How thick data can improve big data analysis for business:How thick data can improve big data analysis for business:
How thick data can improve big data analysis for business:
 
Introducción al machine learning
Introducción al machine learningIntroducción al machine learning
Introducción al machine learning
 
Democratizando el uso de CoDi
Democratizando el uso de CoDiDemocratizando el uso de CoDi
Democratizando el uso de CoDi
 
Gestionando la felicidad de los equipos con Management 3.0
Gestionando la felicidad de los equipos con Management 3.0Gestionando la felicidad de los equipos con Management 3.0
Gestionando la felicidad de los equipos con Management 3.0
 
Taller: Creación de Componentes Web re-usables con StencilJS
Taller: Creación de Componentes Web re-usables con StencilJSTaller: Creación de Componentes Web re-usables con StencilJS
Taller: Creación de Componentes Web re-usables con StencilJS
 
El camino del full stack developer (o como hacemos en SERTI para que no solo ...
El camino del full stack developer (o como hacemos en SERTI para que no solo ...El camino del full stack developer (o como hacemos en SERTI para que no solo ...
El camino del full stack developer (o como hacemos en SERTI para que no solo ...
 
¿Qué significa ser un programador en Bitso?
¿Qué significa ser un programador en Bitso?¿Qué significa ser un programador en Bitso?
¿Qué significa ser un programador en Bitso?
 
Colaboración efectiva entre desarrolladores del cliente y tu equipo.
Colaboración efectiva entre desarrolladores del cliente y tu equipo.Colaboración efectiva entre desarrolladores del cliente y tu equipo.
Colaboración efectiva entre desarrolladores del cliente y tu equipo.
 
Pruebas de integración con Docker en Azure DevOps
Pruebas de integración con Docker en Azure DevOpsPruebas de integración con Docker en Azure DevOps
Pruebas de integración con Docker en Azure DevOps
 
Elixir + Elm: Usando lenguajes funcionales en servicios productivos
Elixir + Elm: Usando lenguajes funcionales en servicios productivosElixir + Elm: Usando lenguajes funcionales en servicios productivos
Elixir + Elm: Usando lenguajes funcionales en servicios productivos
 
Así publicamos las apps de Spotify sin stress
Así publicamos las apps de Spotify sin stressAsí publicamos las apps de Spotify sin stress
Así publicamos las apps de Spotify sin stress
 
Achieving Your Goals: 5 Tips to successfully achieve your goals
Achieving Your Goals: 5 Tips to successfully achieve your goalsAchieving Your Goals: 5 Tips to successfully achieve your goals
Achieving Your Goals: 5 Tips to successfully achieve your goals
 
Acciones de comunidades tech en tiempos del Covid19
Acciones de comunidades tech en tiempos del Covid19Acciones de comunidades tech en tiempos del Covid19
Acciones de comunidades tech en tiempos del Covid19
 
De lo operativo a lo estratégico: un modelo de management de diseño
De lo operativo a lo estratégico: un modelo de management de diseñoDe lo operativo a lo estratégico: un modelo de management de diseño
De lo operativo a lo estratégico: un modelo de management de diseño
 
La importancia de crear User Personas y Escenarios
La importancia de crear User Personas y EscenariosLa importancia de crear User Personas y Escenarios
La importancia de crear User Personas y Escenarios
 
La vida después de la escuela
La vida después de la escuelaLa vida después de la escuela
La vida después de la escuela
 

Predictive Maintenance

  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.
  • 15.
  • 16.
  • 17.
  • 18.
  • 19.
  • 20.
  • 21.
  • 22.
  • 23.
  • 24.
  • 25.
  • 26.
  • 27.
  • 28.
  • 29.
  • 30.
  • 31.
  • 32.
  • 33.
  • 34.
  • 35.
  • 36.
  • 37.
  • 38.
  • 39.
  • 40. 𝑝𝑟𝑒𝑐𝑖𝑠𝑖𝑜𝑛 = 𝑓𝑎𝑖𝑙𝑢𝑟𝑒𝑠 𝑐𝑜𝑟𝑟𝑒𝑐𝑡𝑙𝑦 𝑖𝑑𝑒𝑛𝑡𝑖𝑓𝑖𝑒𝑑 𝑓𝑎𝑖𝑙𝑢𝑟𝑒𝑠 𝑐𝑜𝑟𝑟𝑒𝑐𝑡𝑙𝑦 𝑖𝑑𝑒𝑛𝑡𝑖𝑓𝑖𝑒𝑑+ℎ𝑒𝑎𝑙𝑡ℎ𝑦 𝑒𝑛𝑔𝑖𝑛𝑒𝑠 𝑖𝑛𝑐𝑜𝑟𝑟𝑒𝑐𝑡𝑙𝑦 𝑙𝑎𝑏𝑒𝑙𝑒𝑑 𝑎𝑠 𝑓𝑎𝑖𝑙𝑒𝑑 𝑝𝑟𝑒𝑐𝑖𝑠𝑖𝑜𝑛 = 𝑡𝑟𝑢𝑒 𝑝𝑜𝑠𝑠𝑖𝑡𝑖𝑣𝑒 𝑡𝑟𝑢𝑒 𝑝𝑜𝑠𝑠𝑖𝑡𝑖𝑣𝑒+𝑓𝑎𝑙𝑠𝑒 𝑝𝑜𝑠𝑠𝑖𝑡𝑖𝑣𝑒
  • 41. 𝑟𝑒𝑐𝑎𝑙𝑙 = 𝑡𝑟𝑢𝑒 𝑝𝑜𝑠𝑠𝑖𝑡𝑖𝑣𝑒 𝑡𝑟𝑢𝑒 𝑝𝑜𝑠𝑠𝑖𝑡𝑖𝑣𝑒 + 𝑓𝑎𝑙𝑠𝑒 𝑛𝑒𝑔𝑎𝑡𝑖𝑣𝑒 𝑟𝑒𝑐𝑎𝑙𝑙 = 𝑓𝑎𝑖𝑙𝑢𝑟𝑒𝑠 𝑐𝑜𝑟𝑟𝑒𝑐𝑡𝑙𝑦 𝑖𝑑𝑒𝑛𝑡𝑖𝑓𝑖𝑒𝑑 𝑓𝑎𝑖𝑙𝑢𝑟𝑒𝑠 𝑐𝑜𝑟𝑟𝑒𝑐𝑡𝑙𝑦 𝑖𝑑𝑒𝑛𝑡𝑖𝑓𝑖𝑒𝑑 + 𝑓𝑎𝑢𝑙𝑡𝑦 𝑒𝑛𝑔𝑖𝑛𝑒𝑠 𝑖𝑛𝑐𝑜𝑟𝑟𝑒𝑐𝑡𝑙𝑦 𝑙𝑒𝑏𝑙𝑒𝑑 𝑎𝑠 ℎ𝑒𝑎𝑙𝑡ℎ𝑦
  • 42.
  • 43. 𝐹1 𝑠𝑐𝑜𝑟𝑒 = 2 ∗ 𝑝𝑟𝑒𝑐𝑖𝑠𝑖𝑜𝑛 ∗ 𝑟𝑒𝑐𝑎𝑙𝑙 𝑝𝑟𝑒𝑐𝑖𝑠𝑖𝑜𝑛 + 𝑟𝑒𝑐𝑎𝑙𝑙

Editor's Notes

  1. About a year and a half ago I became an R&D group lead. One day my friend who works with me. Every time he sails he listens to engines, for many years. You need an app that listens for you. Not like any other project – maintenance, engines, mechanics.
  2. lieutenant commander in the Israeli navy In previous roles I served as a software development officer, as an autonomous vehicles navigation algorithm developer and now I serve as head of an R&D group in the navy.
  3. Regular maintenance periods, scheduled in advance. Meant to prevent any failure.
  4. Find a fix, couldn’t prevent. Inconvenient for a car – terrible for a combat ship. Ship can’t go on it’s missions. Other ships go. Spare parts. Customs. Technicians. Preventive – doesn’t prevent everything. Breakdown – is the worst case scenario.
  5. Predicting the future of the engine
  6. Know everything you need to know about the engine. Designs the set of rules.
  7. Collect data to establish behavior. Types of sensors and methods.
  8. Collect data to establish behavior. Types of sensors and methods.
  9. Not even the most sophisticated equipment successfully predicts developing problems unless the operator understands and applies the basics of vibration analysis.
  10. Expensive sensors, infinite budget. Cyber security – sensors based on BT and wifi technology We still need a mechanical engineer to decipher the warnings at the end of the chain
  11. Expensive sensors, infinite budget. Cyber security – sensors based on BT and wifi technology We still need a mechanical engineer to decipher the warnings at the end of the chain
  12. Expensive sensors, infinite budget. Cyber security – sensors based on BT and wifi technology We still need a mechanical engineer to decipher the warnings at the end of the chain
  13. Ship recognition many rules. World of vessels advances. We’re not mechanical engineers, but we see the value of data.
  14. Distinction between 3 engines – data from same sensor – clustering. Distinction of strange noises.
  15. Distinction between 3 engines – data from same sensor – clustering. Distinction of strange noises.
  16. 100 ships, 50 engines on each ship. Each engine, each ship for entire fleet – not cost effective.
  17. התחלנו לחפש דרכים ליצור מוצר שישתמש באחזקה חזויה לגילוי תבניות של כשלים, ושתוכל לספק אזהרות מראש. לצורך ההתחלה, השתמשנו בדאטהסט של נאסא שאני מרחיבה עליו בהמשך. הוא מכיל נתוני התבלות עבור אחד מסוגי המנועים, לחיזוי RUL באמצעות מודלים של REGRSSION.
  18.  הורדת רעשים – לפני שמתחילים בכל התהליכים של העיבוד לצורך הורדת השגיאה, צריך לוודא שאין רעשים שמפריעים למידע שלנו. כאן בוודאות יש רעש שמגיע עם המידע של הסנסורים, אז בכלל לפני שמתחילים את תהליך הורדת השגיאה צריך להוריד את הרעשים. זה נעשה באמצעות AUTOENCODERS.
  19. סנסורים – בתחום הזה של אחזקה חזויה, הדאטה נאסף ע"י סנסורים. הסנסורים האלו מנטרים את ההתנהגות של המנוע. מספר דברים שהיינו צריכים לשים לב אליהם בעבודה מול סנסורים. הדבר הראשון – סנסורים זה עסק יקר. ככל ששמים יותר, כך המידע יותר איכותי ופחות צריך להתעסק עם ניקוי רעשים. מכיוון שהארגון שלנו קצת פחות עשיר מנאסא, לא יכלנו להרשות לעצמנו לשים 20 סנסורים על כל מנוע, אלא סנסור אחד על כל 3 מנועים. דבר נוסף, גם אם היינו רוצים לשים סנסורים בכל פינה, לא יכלנו לעשות זאת מבחינה טכנית, הכלים לא תמיד מאפשרים מבחינת מבנה הכלי. נניח והתגברנו על המכשולים האלה, נשאר לנו מכשול הסייבר. יש אומרים שזה המכשול הכבד ביותר. הרוב המוחלט של הסנסורים מעבירים מידע באמצעות BT או WIFI, או שניהם! נשמע נוח בטירוף. למי שלא בצבא. בצבא זה ביג נו-נו. התגברנו כי מצאנו את הסנסורים שמתאימים לנו בהיבטי בטחון מידע והצפנה.
  20. דאטהסט – נאסא כחלוצה בתחום, אוספים מידע על מצב המנוע כבר עשרות שנים. מ-1990 כמו שראינו בהתחלה, בחלק של ההנדסת מכונות, מזמן. למרבה המזל, נאסא אוהבים לשתף ואפילו מציעים קורסים והכשרות בתחום האחזקה החזויה. נאסא משתפת הרבה מאוד דאטאסטים שיש ברשותה, ובאמת הרוב המוחלט של החברות המתחילות להתעסק באחזקה חזויה באמצעות כלים של דאטה סיינס – מתחילות לאמן את המודלים שלהם על בסיס הדאטהסט של נאסא. (זה נקרא TRANSFER LEARNING.) קשה מאוד להגיע לדאטהסט מלא ואיכותי, זה מצריך שנים של איסוף מידע. הבעיה פה גדולה מאוד, כי מדובר במידע מכני של מכונות אמיתיות, זה לא מידע שאפשר למצוא אותו אם עושים SCRAPING לווב. טיפ ממני – תתחילו לאסוף מידע עכשיו, ואפילו עדיף – אתמול. תודו לי אחר כך.
  21. TIME SERIES DATA – המטרה של כל האירוע הזה של אחזקה חזויה הוא לחזות תקלה בעתיד הקרוב. הכוונה היא שאנחנו מחפשים פה בסוף לקבל תשובה בפורמט זמן. עכשיו אחרי שהבנו מה זה המידע שאנחנו אוספים ומה בדיוק אנחנו רוצים למצוא – שזה זמן, היינו צריכים להסתכל לתוך נבכי הדאטה בעצמו. כל המנועים בדאטהסט הזה הם מאותו הסוג, אבל כל אחד מהמנועים מתחיל בדרגה אחרת של בלאי התחלתי ושינויים כאלה ואחרים בעקבות תהליך הייצור. כל הנתונים האלו לא ידועים למשתמש. הדאטה מכיל ID ייחודי לכל מנוע, תגית זמן, הגדרות וקריאות מ-21 סנסורים.
  22. Distinction between 3 engines – data from same sensor – clustering. Distinction of strange noises.
  23. אז איך מתמודדים עם האתגר? המטרה היא להפחית את השגיאה בין ה-RUL האמיתי ל-RUL החזוי. אנחנו משתמשים בשגיאת RMSE, כי היא מענישה שגיאות גדולות בחומרה. זה מכריח את האלגוריתם לחזות RUL קרוב ככל הניתן. אז אילו אתגרים יש לנו?
  24. MODEL+RAW DATA – שימוש ב RAW DATA אומר שהשתמשנו בדאטה שאספנו מהסנסורים מבלי לבצע מניפולציות או עיבוד למידע. ניסינו להעביר את המידע הזה על מספר אלגוריתמים שקיימים ב SICKIT LEARN. האתגרים בשיפור המודל והקטנת השגיאה מצויים בשלבים הבאים. השלב הראשו הוא בחירת המודל. לצורך בחירת המודל, נשארנו בתחום הקלאסיקל לרנינג בשלב הראשון, כדי לראות מה קורה בשלב בדיקת ההתכנות. לא לוקח הרבה זמן, הדיבוג לא מסובך כמו ברשתות. (למשל FOREST TREE, לינאר רגרשן וכו').
  25. FEATURE ENGINEERING – בצעד הזה אנחנו עוברים לעבד את המידע. מעבדים את המידע ע"י בחירת הפיצ'רים שהכי חוזים מבחינתנו. מציאת הסט של הנכון של הפיצ'רים האלו זה לא פשוט, הצעד הזה הוא אחד הצעדים היותר קשים כשמנסים להעלות את האיכות והאמינות של המוצר. בסופו של דבר, זה אחד האתגרים הקשים ביותר למצוא סט אופטימלי מספיק של פיצ'רים. (לרשום לדוגמה פיצ'רים).
  26. OPTIMIZATION – היפר פרמטרים שולטים בהתנהגות של האלגוריתם שלנו. כיוונון נכון של הפרמטרים האלו אמור לשפר את ה RMSE. יש הרבה דרכים לכוונן את הפרמטרים האלו, למשל באמצעות GRID SEARCH.
  27. Distinction between 3 engines – data from same sensor – clustering. Distinction of strange noises.
  28. כשמתבוננים בתמונה הכללית של הצלחת האלגוריתם, אנחנו כנראה נטעה ונחשוב שאנחנו עושים עבודה טובה כי ה ACCURACY מתקרב ל 100%. יכול להיות שאנחנו עומדים מול מקרה חמור של חוסר איזון.
  29. CLASS BALANCE – בדאטה שלנו רוב הזמן המנועים שלנו נמצאים במצב טוב ונשאר להם הרבה זמן לעבוד. יש לנו משמעותית פחות דוגמאות של מנועים שיש להם קצת זמן לעבוד. רוב הזמן שאני אנחש שהמנוע עובד אני כנראה אהיה צודקת. למרות שזו בעיית רגרשן ולא קלסיפיקיישן, יש לנו כאן שתי קטגוריות – מנוע שיש לו הרבה זמן עבודה ומנוע שיש לו מעט זמן עבודה – אחת הקטגוריות מייצגת את הרוב הסופר מוחלט של הדאטהפוינטס. ייצוג יתר יוצר חוסר איזון. משימות כמו שלנו עלולות להוביל למודלים בעלי אחוז דיוק גבוה מאוד, אבל עם יכולות חיזוי עלובות. באתגר כזה נשתמש ב BFFS שלנו – פרסיז'ן וריקול.
  30. פרסיז'ן וריקול הם שני כלים מתמטיים שעוזרים לנו להבין אם המערכת שלנו נמצאת בחוסר איזון. להוסיף דוגמה על חיזוי קליקים – איך חוזים האם למפרסם שווה לפרסם אם הרוב הם "לא קליק".
  31. PRECISION – מציג יחס בין המספר של הערכים האמיתיים שנחזו לחלק במספר כל הערכים שנחזו, שמכיל גם את ה FALSE POSITIVES. מתרגמת את האפס ואחד של הקלאסיפיקציה הבינארית להרבה זמן ומעט זמן עבור מידע רציף עד לתקלה ברגרשן.
  32. RECALL – מציג יחס בין המספר של הערכים האמיתיים שנחזו לחלק בכל הערכים שנחזו והFALSE NEGATIVES. חיובי אמיתי – מנוע שבאמת תקול נחזה כמנוע תקול. FALSE NEGATIVE – מנוע שבאמת תקול נחזה כמנוע שבאמת תקין, כשהוא בכלל תקול. ריקול נותן לנו את כל הדאטהפוינטס שמעניינות אותנו בדאטהסט. (לחפש את האינטואיציה של מה משתמשים בשניהם).
  33. ACCURACY – משלב בתוכו את פרסיז'ן וריקול. על מנת למדוד את הדיוק של המבחן, אנחנו צריכים להשתמש גם בריקול וגם בפרסיז'ן. יש כל מני דרכים להשתמש בשניהם ולמצע אותם איכשהו, השיטה הרווחת ביותר היא F1 SCORE.
  34. F1 SCORE הוא הממוצע ההרמוני של פרסיז'ן וריקול. זו שיטה מוכרת ויותר טובה למקרה שלנו במקום ממוצע רגיל, כי היא מענישה ערכים מוגזמים. אנחנו רוצים למקסם את ה-F1 SCORE כדי לקבל קלסיפיקציה מאוזנת.
  35. עצירה לשתייה
  36. RUN – לסיכום כל התהליך, כשמנסים להטמיע מודל באמצעות כלים של ML אנחנו צריכים לעבור מספר שלבים. 1. לעבור בכל השלבים של עיבוד המידע, כולל ניקוי רעשים, פיצ'ר אנג'נירינג וכוונון היפר פרמטרז. 2. בחינת דיוק החיזוי שמבצע המודל שלנו באמצעות F1 SCORE. 3. החזרת התוצאות ומעבר ציקלי על התהליך לשיפור הדיוק והאמינות. בנוסף לשלבים אלו, שרלוונטיים עבור כל פרויקט בדאטה סיינס, יש דברים שחשוב לשים אליהם לב במיוחד בפרויקט כזה של אחזקה חזויה:
  37. כל השלבים אותם עוברים דורשים כמות פסיכית של דאטה לאימון. זה לא סתם שכל החברות שמתחילות לעסוק בתחום האחזקה החזויה קודם כל מאמנות מודלים על הדאטהסט של הטורבופן של נאסא. כמעט בלתי אפשרי למצוא מידע כזה יושב לו באינטרנט. החשיבות של איסוף המידע בתחום המכונות מתחילה להכנס לפוקוס רק ממש בשנה-שנתיים האחרונות.
  38. כשאנחנו מנסים לשפר את המודל שלנו, אנחנו צריכים להבין שהמערכת יחסים בין ה RUL למידע המתקבל מהסנסורים הוא לא לינארי. את ההתפלגות של הערכים שהסנסור מעביר עבור מנועים בריאים צריך להשוות לסט דומה כשהמנוע מתקרב לתקלה. כל הזמן בו המנוע בריא – הגיוני לחשוב על ה-RUL שלו כעל קבוע. רק כשמנוע מתחיל לשפוך מנוע, איזשהו קבוע זמן לפני סוף החיים שלו, ה-RUL שלו יתחיל להיות מושפע. אם יש לי עוד 700 צעדים או 705 צעדים לתקלה זה לא מעניין אותי כמו ההבדל בין 25 ל-20 צעדים.
  39. גישת שמבוססת על מודלים ולמידה שונה מהגישה הפיסיקלית המבוססת על חוקים בהמון היבטים. הסיבה החזקה ביותר שיש לנו לבחירת גישה שמבוססת על מודלים ולמידה היא החישוב. המודל הפיזיקלי מניח את קצב הבלאי – מהיכרותו עם סוג המנוע. לעומת זאת DS לא מניח שום קצב ויכול לתפוס תקלה לא משנה מתי ואיך היא קורית. כרגע אין לנו מספיק דאטה אז לומדים גם מדאטה של נאסא וגם משלנו, את הטסטסט נרצה לבדוק באמצעות דאטה שלנו כדי לראות איך המוצר שלנו באמת מגיב לנתונים אמיתיים עבור המכונות שלנו. להרחיב על הפיצ'רים ואיך זה יכול להשפיע על טיפולים תקופתיים, איך חיזוי משפיע על טיפולים תקופתיים.
  40. כשנכנסנו לפרויקט כמובן שלא הכל היה קל ופשוט ונתקלנו בהמון בעיות מכל מני סוגים.
  41. Ours is not the first nor last predictive maintenance project. The space and car industry are highly experienced. Every major car company has a division in its R&D center – dealing with predictive maintenance. NASA, shipyards worldwide – everybody does it.
  42. Ours is not the first nor last predictive maintenance project. The space and car industry are highly experienced. Every major car company has a division in its R&D center – dealing with predictive maintenance. NASA, shipyards worldwide – everybody does it.
  43. Ours is not the first nor last predictive maintenance project. The space and car industry are highly experienced. Every major car company has a division in its R&D center – dealing with predictive maintenance. NASA, shipyards worldwide – everybody does it.
  44. Ours is not the first nor last predictive maintenance project. The space and car industry are highly experienced. Every major car company has a division in its R&D center – dealing with predictive maintenance. NASA, shipyards worldwide – everybody does it.
  45. על מנת להטמיע מודל אנחנו צריכים לחבר את כל השלבים שעברנו עד עכשיו לניסוי אחד עם ציון. אין דרך אחת להטמיע מודלים שיעבדו בכל סיטואציה שלא תהיה. הארגון צריך להיות מספיק גמיש ולהחליט על אילו משתנים הוא מוכן לוותר ומה התמורה אותה הוא מבקש לקבל. מה חשוב לו באמת. האם ריל טיים הכרחי? האם מהירות הכרחית? במקרה שלנו, ריל טיים לא הכרחי לנו. אם קורית תקלה בים, מאד לא סביר שנצליח לתקן אותה באותו הרגע, הדרדרנו כבר לאחזקת שבר – המקרה הגרוע ביותר. חשוב לנו לצפות אותה מראש כדי לא להיתקע במצב הזה בלב ים. חשוב מאוד גם לזכור את המשאבים הנדרשים לתחזוקה ותמיכת המערכת. זו עלולה להיות בעיה גדולה לסטארטאפים קטנים, אבל ארגונים גדולים יכולים להתמודד איתה. שוב, מאוד תלוי בארגון.
  46. Ours is not the first nor last predictive maintenance project. The space and car industry are highly experienced. Every major car company has a division in its R&D center – dealing with predictive maintenance. NASA, shipyards worldwide – everybody does it.
  47. MARKER REVENUE – אחזקה חזויה היא אחת הדוגמאות הקלאסיות ב-IOT התעשייתי וב-INDUSTRY 4.0. מחקרים שנעשו בשנה האחרונה על שוק האחזקה החזויה הראו שהשוק שהוערך ב 2017 בכ-2.2 מיליארד דולר צפוי להגיע לכ-10.9 מיליארד דולר בשנת 2022, שזה ממש תכף. העלייה השנתית ברווחים עבור שוק זה היא כ-39% עלייה בשנה. זה מטורף. זה בהחלט שוק ששווה להשקיע בו, ועכשיו זה הזמן. חשוב לציין שהמספרים האלו נוגעים למימוש של אחזקה חזויה בכלים של דאטה סיינס. היום משתמשים במונח אחזקה חזויה כבאז וורד יותר מדיי, וחשוב לעשות את ההפרדה. כמו שראינו בהתחלה של המצגת – לא כל פתרון אחזקה הוא בעל יכולות חיזוי.
  48. MARKER REVENUE – אחזקה חזויה היא אחת הדוגמאות הקלאסיות ב-IOT התעשייתי וב-INDUSTRY 4.0. מחקרים שנעשו בשנה האחרונה על שוק האחזקה החזויה הראו שהשוק שהוערך ב 2017 בכ-2.2 מיליארד דולר צפוי להגיע לכ-10.9 מיליארד דולר בשנת 2022, שזה ממש תכף. העלייה השנתית ברווחים עבור שוק זה היא כ-39% עלייה בשנה. זה מטורף. זה בהחלט שוק ששווה להשקיע בו, ועכשיו זה הזמן. חשוב לציין שהמספרים האלו נוגעים למימוש של אחזקה חזויה בכלים של דאטה סיינס. היום משתמשים במונח אחזקה חזויה כבאז וורד יותר מדיי, וחשוב לעשות את ההפרדה. כמו שראינו בהתחלה של המצגת – לא כל פתרון אחזקה הוא בעל יכולות חיזוי.
  49. You can do it too! Our project may serve a specific purpose, for a specific corporation, but predictive maintenance can be done anywhere. Hard drives life cycle example. Any machine you can think of. NASA has a great database of engine sounds, that’s a good place to start experimenting. ישנם מימושים רבים לאחזקה חזויה בתעשייה – ממימושים תעשייתיים עד אנליזות תוכנה.
  50. סימנס לדוגמה, הריצו פיילוט אחזקה חזויה במשך 12 חודשים יחד עם דויטשה באן, הרכבת הגרמנית, כדי לנטר את צי רכבות ה ICE 407.
  51. מייקרוסופט לדוגמה, הוציאה מנוע אנליטי חזק למידול אחזקה חזויה, ועטפה אותו ב UI מאוד נוח כדי שכל חברה שתרצה להכנס לתחום האחזקה החזויה תוכל להכנס בצורה חלקה ונוחה ולהשתמש במודלים קיימים. מחקרי שוק הראו גם שיותר יישומים של אחזקה חזויה עוברים ממימושים ON PREMISE למימוש בענן – עד 2022 בערך 70% מכל המימושים צפויים להיות מבוססים בענן.
  52. Imagine a world. Not the future, it’s the present. Present of advanced companies, my dream is to see it on my ship.
  53. The world is full of data, the future is using it for the right projects. Data science is the bridge between the old world of machines to a new and improved world of machines that learn. I invite you all to do predictive maintenance with me! Thank you.
  54. lieutenant commander in the Israeli navy In previous roles I served as a software development officer, as an autonomous vehicles navigation algorithm developer and now I serve as head of an R&D group in the navy.