Як Carrier прогнозує несправності HVAC за допомогою AWS Glue і Amazon SageMaker | Веб-сервіси Amazon

За їх власними словами, «У 1902 році Вілліс Керрієр вирішив одну з найбільш важкодосяжних проблем людства щодо контролю внутрішнього середовища за допомогою сучасного кондиціонування повітря. Сьогодні продукти Carrier створюють комфортне середовище, захищають глобальне постачання продовольства та забезпечують безпечне транспортування життєво важливих медичних товарів у суворих умовах».

At Перевізникосновою нашого успіху є створення продуктів, яким наші клієнти можуть довіряти, щоб забезпечити їм комфорт і безпеку протягом усього року. Висока надійність і низький час простою обладнання стають все більш важливими, оскільки екстремальні температури стають більш поширеними через зміну клімату. Історично ми покладалися на системи на основі порогових значень, які сповіщали нас про ненормальну поведінку обладнання за допомогою параметрів, визначених нашою командою інженерів. Хоча такі системи є ефективними, вони призначені для виявлення та діагностики проблем з обладнанням, а не для їх прогнозування. Прогнозування несправностей до їх виникнення дозволяє нашим дилерам HVAC завчасно вирішувати проблеми та покращувати взаємодію з клієнтами.

Щоб підвищити надійність нашого обладнання, ми співпрацюємо з Лабораторія рішень машинного навчання Amazon розробити спеціальну модель машинного навчання (ML), здатну передбачати проблеми з обладнанням до виходу з ладу. Наші команди розробили структуру для обробки понад 50 ТБ історичних даних датчиків і прогнозування несправностей із точністю 91%. Тепер ми можемо повідомляти дилерів про загрозу поломки обладнання, щоб вони могли планувати перевірки та мінімізувати час простою агрегату. Структура рішення є масштабованою, оскільки встановлюється більше обладнання, і її можна повторно використовувати для різноманітних подальших завдань моделювання.

У цій публікації ми показуємо, як команди Carrier і AWS застосували ML для прогнозування несправностей у великих парках обладнання за допомогою однієї моделі. Спочатку ми висвітлюємо, як ми використовуємо Клей AWS для високопаралельної обробки даних. Потім обговорюємо, як Amazon SageMaker допомагає нам у розробці функцій і розробці масштабованої моделі глибокого навчання під наглядом.

Огляд варіантів використання, цілей і ризиків

Основна мета цього проекту – скоротити час простою шляхом прогнозування несправностей обладнання та сповіщення дилерів. Це дозволяє дилерам завчасно планувати технічне обслуговування та забезпечувати виняткове обслуговування клієнтів. Працюючи над цим рішенням, ми зіткнулися з трьома основними проблемами:

• Масштабованість даних – Обробка даних і виділення функцій повинні масштабуватися на великі зростаючі історичні дані датчиків
• Масштабованість моделі – Підхід до моделювання має бути здатним масштабувати понад 10,000 XNUMX одиниць
• Точність моделі – Щоб уникнути непотрібних перевірок технічного обслуговування, необхідний низький рівень помилкових позитивних результатів

Масштабованість, як з точки зору даних, так і з точки зору моделювання, є ключовою вимогою до цього рішення. У нас є понад 50 ТБ даних про обладнання за попередні періоди, і ми очікуємо, що ці дані швидко збільшуватимуться, оскільки більше блоків HVAC буде підключено до хмари. Обробка даних і моделювання потребують масштабування в міру зростання обсягу даних. Для того, щоб наш підхід до моделювання охопив понад 10,000 XNUMX одиниць, нам потрібна модель, яка може навчатися на парку обладнання, а не покладатися на аномальні показники для окремого пристрою. Це забезпечить узагальнення між одиницями та зменшить вартість висновків завдяки розміщенню однієї моделі.

Іншою проблемою для цього випадку використання є спрацьовування помилкових тривог. Це означає, що дилер або технік виїде на місце, щоб перевірити обладнання клієнта та переконатися, що все працює належним чином. Рішення вимагає високоточної моделі, яка гарантує, що коли дилер отримає сповіщення, обладнання, ймовірно, вийде з ладу. Це допомагає завоювати довіру як дилерів, техніків, так і домовласників, а також зменшує витрати, пов’язані з непотрібними перевірками на місці.

Ми співпрацювали з експертами зі штучного інтелекту та ML в Amazon ML Solutions Lab для 14-тижневої розробки. Зрештою, наше рішення включає два основні компоненти. Перший — це модуль обробки даних, створений за допомогою AWS Glue, який узагальнює поведінку обладнання та зменшує розмір наших навчальних даних для ефективної подальшої обробки. По-друге, це інтерфейс навчання моделі, яким керує SageMaker, який дозволяє нам навчати, налаштовувати та оцінювати нашу модель перед її розгортанням у робочій кінцевій точці.

Обробка даних

Кожна установка HVAC, яку ми встановлюємо, генерує дані з 90 різних датчиків із показаннями обертів, температури та тиску в усій системі. Це становить приблизно 8 мільйонів точок даних, які генеруються на один пристрій на день із десятками тисяч встановлених пристроїв. Оскільки все більше систем опалення, вентиляції та кондиціонування підключаються до хмари, ми очікуємо швидкого зростання обсягу даних, що робить критичним для нас керування їх розміром і складністю для використання в наступних завданнях. Тривалість історії даних датчика також представляє проблему моделювання. Пристрій може почати відображати ознаки загрозливої ​​несправності за місяці до того, як несправність фактично спрацює. Це створює значну затримку між передбачуваним сигналом і фактичним збоєм. Метод стиснення довжини вхідних даних стає критичним для моделювання ML.

Щоб вирішити розмір і складність даних датчиків, ми стискаємо їх у циклічні функції, як показано на малюнку 1. Це значно зменшує розмір даних, одночасно фіксуючи характеристики, які характеризують поведінку обладнання.

AWS Glue — це безсерверна служба інтеграції даних для обробки великої кількості даних у масштабі. AWS Glue дозволив нам легко запускати паралельну попередню обробку даних і вилучення функцій. Ми використовували AWS Glue для виявлення циклів і узагальнення поведінки агрегату за допомогою ключових функцій, визначених нашою командою інженерів. Це різко зменшило розмір нашого набору даних з понад 8 мільйонів точок даних на день на одиницю до приблизно 1,200. Важливо те, що цей підхід зберігає прогнозовану інформацію про поведінку пристрою з набагато меншим обсягом даних.

Результатом роботи AWS Glue є підсумкова інформація про поведінку одиниці для кожного циклу. Потім ми використовуємо an Обробка Amazon SageMaker обчислити функції в циклах і позначити наші дані. Ми формулюємо задачу ML як задачу бінарної класифікації з метою прогнозування несправностей обладнання в наступні 60 днів. Це дозволяє нашій дилерській мережі своєчасно усувати можливі несправності обладнання. Важливо зазначити, що не всі пристрої виходять з ладу протягом 60 днів. Пристрій, який відчуває повільне зниження продуктивності, може зайняти більше часу, щоб вийти з ладу. Ми розглядаємо це під час етапу оцінки моделі. Ми зосередили наше моделювання на літньому періоді, оскільки в ці місяці більшість систем опалення, вентиляції, вентиляції та кондиціонування повітря в США працюють стабільно та в більш екстремальних умовах.

Моделювання

Архітектури трансформаторів стали найсучаснішим підходом до обробки тимчасових даних. Вони можуть використовувати довгі послідовності історичних даних на кожному кроці часу, не страждаючи від зникаючих градієнтів. Вхідні дані для нашої моделі в певний момент часу складаються з характеристик для попередніх 128 циклів обладнання, що становить приблизно один тиждень роботи установки. Це обробляється тришаровим кодувальником, вихідні дані якого усереднюються та подаються в багаторівневий класифікатор персептрона (MLP). Класифікатор MLP складається з трьох лінійних рівнів із функціями активації ReLU та останнього рівня з активацією LogSoftMax. Ми використовуємо зважену від’ємну втрату логарифмічної ймовірності з іншою вагою для позитивного класу для нашої функції втрат. Це зміщує нашу модель у бік високої точності та дозволяє уникнути дорогих помилкових тривог. Це також включає наші бізнес-цілі безпосередньо в процес навчання моделі. Рисунок 2 ілюструє архітектуру трансформатора.

Навчання

Однією з проблем під час навчання цієї моделі тимчасового навчання є дисбаланс даних. Деякі одиниці мають довшу історію експлуатації, ніж інші, і тому мають більше циклів у нашому наборі даних. Оскільки вони надмірно представлені в наборі даних, ці одиниці матимуть більший вплив на нашу модель. Ми вирішуємо це шляхом випадкової вибірки 100 циклів в історії пристрою, де ми оцінюємо ймовірність відмови в цей момент. Це гарантує однакову представленість кожного підрозділу під час навчального процесу. Усуваючи проблему незбалансованих даних, цей підхід має додаткову перевагу відтворення підходу пакетної обробки, який використовуватиметься у виробництві. Цей підхід до вибірки було застосовано до наборів для навчання, перевірки та тестування.

Навчання проводилося з використанням GPU-прискореного екземпляра на SageMaker. Моніторинг втрат показує, що він досягає найкращих результатів після 180 епох навчання, як показано на малюнку 3. На малюнку 4 показано, що площа під кривою ROC для отриманої моделі часової класифікації становить 81%.

Малюнок 3: Втрати навчання протягом епох

Рисунок 4: ROC-AUC для 60-денного блокування

Оцінка

Хоча наша модель навчається на рівні циклу, оцінювання має відбуватися на рівні підрозділу. Таким чином, одна одиниця з кількома справжніми позитивними виявленнями все ще зараховується як одна справжня позитивна на рівні одиниці. Для цього ми аналізуємо перекриття між прогнозованими результатами та 60-денним вікном, що передує несправності. Це показано на наступному малюнку, який показує чотири випадки прогнозування результатів:

• Справжній негатив – Усі результати прогнозу негативні (фіолетовий) (Малюнок 5)
• Хибно позитивний – Позитивні прогнози є помилковими тривогами (Малюнок 6)
• Помилковий негатив – Хоча всі прогнози негативні, фактичні мітки можуть бути позитивними (зелені) (Малюнок 7)
• Справжній позитив – Деякі прогнози можуть бути негативними (зелений), і принаймні один прогноз є позитивним (жовтий) (Малюнок 8)

Рисунок 5.1: Справжній негативний випадок	Малюнок 5.2: Хибнопозитивний випадок
Малюнок 5.3: Хибно негативний випадок	Рисунок 5.4: Справжній позитивний випадок

Після навчання ми використовуємо набір оцінок, щоб налаштувати поріг для надсилання сповіщення. Встановлення порогу достовірності моделі на рівні 0.99 дає точність приблизно 81%. Це не відповідає нашому початковому 90% критерію успіху. Однак ми виявили, що значна частина одиниць вийшла з ладу за межами 60-денного вікна оцінювання. Це має сенс, оскільки пристрій може активно демонструвати помилкову поведінку, але для виходу з ладу потрібно більше 60 днів. Щоб впоратися з цим, ми визначили метрику під назвою ефективна точність, що є поєднанням справжньої позитивної точності (81%) із додатковою точністю блокувань, які відбулися протягом 30 днів після нашого цільового 60-денного вікна.

Для дилера HVAC найбільш важливим є те, що перевірка на місці допомагає запобігти майбутнім проблемам HVAC для клієнта. Використовуючи цю модель, ми оцінюємо, що в 81.2% випадків перевірка запобіжить блокуванню протягом наступних 60 днів. Крім того, у 10.4% випадків блокування відбулося протягом 90 днів після перевірки. Решта 8.4% будуть помилковою тривогою. Ефективна точність тренованої моделі становить 91.6%.

Висновок

У цій публікації ми показали, як наша команда використовувала AWS Glue і SageMaker для створення масштабованого контрольованого навчального рішення для прогнозованого обслуговування. Наша модель здатна фіксувати тенденції в довгостроковій історії даних датчиків і точно виявляти сотні несправностей обладнання на тиждень наперед. Попереднє передбачення несправностей скоротить час від бордюру до бордюру, дозволяючи нашим дилерам надавати більш своєчасну технічну допомогу та покращуючи загальний досвід обслуговування клієнтів. Вплив цього підходу з часом зростатиме, оскільки щороку встановлюється все більше блоків HVAC, підключених до хмари.

Наш наступний крок — інтегрувати цю інформацію в майбутній випуск порталу підключених дилерів Carrier. Портал поєднує ці прогнозні сповіщення з іншими статистичними даними, які ми отримуємо з нашого озера даних на основі AWS, щоб надати нашим дилерам більше ясності щодо справності обладнання в усій їхній клієнтській базі. Ми продовжуватимемо вдосконалювати нашу модель, інтегруючи дані з додаткових джерел і витягаючи з даних наших датчиків додаткові функції. Методи, використані в цьому проекті, забезпечують міцну основу для нашої команди, щоб почати відповідати на інші ключові запитання, які можуть допомогти нам зменшити гарантійні претензії та підвищити ефективність обладнання в польових умовах.

Якщо вам потрібна допомога у прискоренні використання ML у ваших продуктах та послугах, будь ласка, зв’яжіться з Лабораторія рішень Amazon ML. Щоб дізнатися більше про послуги, які використовуються в цьому проекті, зверніться до Посібник розробника AWS Glue і Посібник розробника Amazon SageMaker.

---

Про авторів

Раві Патанкар є технічним керівником аналітики, пов’язаної з Інтернетом речей, у підрозділі житлових систем клімат-контролю Carrier. Він формулює проблеми аналітики, пов’язані з діагностикою та прогнозуванням, і надає напрямки для аналітичних рішень і архітектури на основі ML/глибокого навчання.

Ден Волк є спеціалістом з обробки даних у Центрі інновацій AWS Generative AI. Він має десятирічний досвід у машинному навчанні, глибокому навчанні та аналізі часових рядів, а також має ступінь магістра з наук про дані в Каліфорнійському університеті в Берклі. Він захоплений тим, щоб перетворити складні бізнес-завдання на можливості, використовуючи передові технології ШІ.

Інвей Ю є прикладним науковцем у Центрі інновацій AWS Generative AI. Він має досвід роботи з декількома організаціями в різних галузях над різними доказами концепцій машинного навчання, включаючи НЛП, аналіз часових рядів і генеративні технології ШІ. Інвей отримав ступінь доктора філософії з інформатики в Техаському університеті A&M.

Яньсян Ю є прикладним науковцем в Amazon Web Services, працює в Центрі інновацій Generative AI. Маючи понад 8 років досвіду створення моделей штучного інтелекту та машинного навчання для промислових застосувань, він спеціалізується на генеративному штучному інтелекті, комп’ютерному зорі та моделюванні часових рядів. Його робота зосереджена на пошуку інноваційних способів застосування передових генеративних методів до проблем реального світу.

Дієго Соколінскі є старшим менеджером із прикладних наук у Центрі інновацій AWS Generative AI, де він очолює команду доставки для регіонів Східної Америки та Латинської Америки. Він має понад двадцятирічний досвід роботи в галузі машинного навчання та комп’ютерного зору, а також має ступінь доктора філософії з математики в Університеті Джона Гопкінса.

Кесінь Дін є п'ятим курсом Ph.D. кандидат інформатики в UNC-Charlotte. Її дослідження зосереджені на застосуванні методів глибокого навчання для аналізу мультимодальних даних, у тому числі медичних зображень і даних секвенування генома.

• Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
• PlatoData.Network Vertical Generative Ai. Додайте собі сили. Доступ тут.
• PlatoAiStream. Web3 Intelligence. Розширення знань. Доступ тут.
• ПлатонЕСГ. Автомобільні / електромобілі, вуглець, CleanTech, Енергія, Навколишнє середовище, Сонячна, Поводження з відходами. Доступ тут.
• PlatoHealth. Розвідка про біотехнології та клінічні випробування. Доступ тут.
• ChartPrime. Розвивайте свою торгову гру за допомогою ChartPrime. Доступ тут.
• BlockOffsets. Модернізація екологічної компенсаційної власності. Доступ тут.
• джерело: https://aws.amazon.com/blogs/machine-learning/how-carrier-predicts-hvac-faults-using-aws-glue-and-amazon-sagemaker/