Hur Carrier förutsäger HVAC-fel med AWS Glue och Amazon SageMaker | Amazon webbtjänster

Med deras egna ord, "År 1902 löste Willis Carrier en av mänsklighetens mest svårfångade utmaningar att kontrollera inomhusmiljön genom modern luftkonditionering. Idag skapar Carriers produkter bekväma miljöer, säkerställer den globala livsmedelsförsörjningen och möjliggör säker transport av viktiga medicinska förnödenheter under krävande förhållanden."

At Bärare, grunden för vår framgång är att tillverka produkter som våra kunder kan lita på för att hålla dem bekväma och säkra året runt. Hög tillförlitlighet och låga stilleståndstider blir allt viktigare i takt med att extrema temperaturer blir vanligare på grund av klimatförändringar. Vi har historiskt förlitat oss på tröskelbaserade system som varnar oss för onormalt utrustningsbeteende, med hjälp av parametrar som definierats av vårt ingenjörsteam. Även om sådana system är effektiva, är de avsedda att identifiera och diagnostisera utrustningsproblem snarare än att förutsäga dem. Genom att förutsäga fel innan de uppstår kan våra VVS-återförsäljare proaktivt ta itu med problem och förbättra kundupplevelsen.

För att förbättra vår utrustnings tillförlitlighet samarbetade vi med Amazon Machine Learning Solutions Lab att utveckla en anpassad maskininlärningsmodell (ML) som kan förutsäga utrustningsproblem före fel. Våra team utvecklade ett ramverk för att bearbeta över 50 TB historisk sensordata och förutsäga fel med 91 % precision. Vi kan nu meddela återförsäljare om förestående utrustningsfel, så att de kan schemalägga inspektioner och minimera driftstopp. Lösningsramverket är skalbart eftersom mer utrustning installeras och kan återanvändas för en mängd olika nedströmsmodelleringsuppgifter.

I det här inlägget visar vi hur Carrier- och AWS-teamen tillämpade ML för att förutsäga fel i stora utrustningsflottor med en enda modell. Vi belyser först hur vi använder AWS-lim för mycket parallell databehandling. Vi diskuterar sedan hur Amazon SageMaker hjälper oss med funktionsutveckling och att bygga en skalbar modell för övervakad djupinlärning.

Översikt över användningsfall, mål och risker

Huvudmålet med detta projekt är att minska stilleståndstiden genom att förutsäga förestående utrustningsfel och meddela återförsäljarna. Detta gör att återförsäljare kan planera underhåll proaktivt och ge exceptionell kundservice. Vi stod inför tre primära utmaningar när vi arbetade med den här lösningen:

• Data skalbarhet – Databearbetning och funktionsextraktion behöver skalas över stora växande historiska sensordata
• Modellens skalbarhet – Modelleringsmetoden måste kunna skalas över över 10,000 XNUMX enheter
• Modellprecision – Låga falska positiva värden behövs för att undvika onödiga underhållsinspektioner

Skalbarhet, både ur ett data- och modelleringsperspektiv, är ett nyckelkrav för denna lösning. Vi har över 50 TB historisk utrustningsdata och förväntar oss att denna data kommer att växa snabbt när fler HVAC-enheter ansluts till molnet. Databearbetning och modellinferens måste skalas i takt med att vår data växer. För att vår modelleringsmetod ska skala över över 10,000 XNUMX enheter behöver vi en modell som kan lära av en utrustningsflotta snarare än att förlita sig på onormala avläsningar för en enda enhet. Detta kommer att möjliggöra generalisering över enheter och minska kostnaden för slutledning genom att vara värd för en enda modell.

Det andra problemet för detta användningsfall är att utlösa falska larm. Detta innebär att en återförsäljare eller tekniker kommer att gå på plats för att inspektera kundens utrustning och se att allt fungerar som det ska. Lösningen kräver en modell med hög precision för att säkerställa att när en återförsäljare larmas kommer utrustningen sannolikt att gå sönder. Detta hjälper återförsäljare, tekniker och husägare att få förtroende och minskar kostnaderna för onödiga inspektioner på plats.

Vi samarbetade med AI/ML-experterna på Amazon ML Solutions Lab för en 14-veckors utvecklingsinsats. I slutändan innehåller vår lösning två primära komponenter. Den första är en databehandlingsmodul byggd med AWS Glue som sammanfattar utrustningens beteende och minskar storleken på vår träningsdata för effektiv nedströmsbehandling. Det andra är ett modellträningsgränssnitt som hanteras genom SageMaker, vilket gör att vi kan träna, ställa in och utvärdera vår modell innan den distribueras till en produktionsslutpunkt.

Databearbetning

Varje VVS-enhet vi installerar genererar data från 90 olika sensorer med avläsningar för varvtal, temperatur och tryck i hela systemet. Detta uppgår till ungefär 8 miljoner datapunkter som genereras per enhet och dag, med tiotusentals enheter installerade. När fler HVAC-system är anslutna till molnet, förväntar vi oss att volymen data kommer att växa snabbt, vilket gör det avgörande för oss att hantera dess storlek och komplexitet för användning i nedströmsuppgifter. Längden på sensordatahistoriken utgör också en modelleringsutmaning. En enhet kan börja visa tecken på förestående fel månader innan ett fel faktiskt utlöses. Detta skapar en betydande fördröjning mellan den prediktiva signalen och det faktiska felet. En metod för att komprimera längden på indata blir kritisk för ML-modellering.

För att ta itu med storleken och komplexiteten hos sensordata komprimerar vi dem till cykelfunktioner som visas i figur 1. Detta minskar dramatiskt storleken på data samtidigt som vi fångar in funktioner som kännetecknar utrustningens beteende.

AWS Glue är en serverlös dataintegrationstjänst för bearbetning av stora mängder data i stor skala. AWS Glue gjorde det möjligt för oss att enkelt köra parallell dataförbearbetning och funktionsextraktion. Vi använde AWS Glue för att upptäcka cykler och sammanfatta enhetens beteende med hjälp av nyckelfunktioner som identifierats av vårt ingenjörsteam. Detta minskade dramatiskt storleken på vår datauppsättning från över 8 miljoner datapunkter per dag och enhet ner till ungefär 1,200 XNUMX. Det är avgörande att detta tillvägagångssätt bevarar prediktiv information om enhetens beteende med ett mycket mindre datafotavtryck.

Utdata från AWS-limjobbet är en sammanfattning av enhetens beteende för varje cykel. Vi använder sedan en Amazon SageMaker-bearbetning jobb med att beräkna funktioner över cykler och märka våra data. Vi formulerar ML-problemet som en binär klassificeringsuppgift med ett mål att förutsäga utrustningsfel under de kommande 60 dagarna. Detta gör att vårt återförsäljarnätverk kan åtgärda potentiella utrustningsfel i tid. Det är viktigt att notera att inte alla enheter misslyckas inom 60 dagar. En enhet som upplever långsam prestandaförsämring kan ta längre tid att misslyckas. Vi tar upp detta under modellutvärderingssteget. Vi fokuserade vår modellering på sommartid eftersom de månaderna är när de flesta HVAC-system i USA är i konsekvent drift och under mer extrema förhållanden.

Modellering

Transformatorarkitekturer har blivit det senaste tillvägagångssättet för hantering av tidsdata. De kan använda långa sekvenser av historiska data vid varje tidssteg utan att drabbas av försvinnande gradienter. Indata till vår modell vid en given tidpunkt är sammansatt av funktionerna för de tidigare 128 utrustningscyklerna, vilket är ungefär en veckas drift. Detta bearbetas av en treskiktskodare vars utsignal beräknas som medelvärde och matas in i en multi-layered perceptron (MLP) klassificerare. MLP-klassificeraren är sammansatt av tre linjära lager med ReLU-aktiveringsfunktioner och ett sista lager med LogSoftMax-aktivering. Vi använder viktad negativ log-sannolikhetsförlust med en annan vikt på den positiva klassen för vår förlustfunktion. Detta riktar vår modell mot hög precision och undviker kostsamma falsklarm. Den införlivar också våra affärsmål direkt i modellutbildningsprocessen. Figur 2 illustrerar transformatorns arkitektur.

Utbildning

En utmaning när man tränar denna tidsmässiga inlärningsmodell är dataobalans. Vissa enheter har en längre drifthistorik än andra och har därför fler cykler i vår datauppsättning. Eftersom de är överrepresenterade i datasetet kommer dessa enheter att ha mer inflytande på vår modell. Vi löser detta genom att slumpmässigt ta 100 cykler i en enhets historia där vi bedömer sannolikheten för ett fel vid den tidpunkten. Detta säkerställer att varje enhet är lika representerad under utbildningsprocessen. Samtidigt som problemet med obalanserad data tas bort, har detta tillvägagångssätt den extra fördelen att det replikerar en batchbearbetningsmetod som kommer att användas i produktionen. Denna provtagningsmetod tillämpades på tränings-, validerings- och testseten.

Träning utfördes med en GPU-accelererad instans på SageMaker. Övervakning av förlusten visar att den uppnår de bästa resultaten efter 180 träningsepoker som visas i figur 3. Figur 4 visar att arean under ROC-kurvan för den resulterande tidsklassificeringsmodellen är 81 %.

Figur 3: Träningsförlust under epoker

Figur 4: ROC-AUC för 60 dagars lockout

Utvärdering

Medan vår modell tränas på cykelnivå behöver utvärdering ske på enhetsnivå. På detta sätt räknas en enhet med flera sanna positiva detektioner fortfarande bara som en enda sann positiv på enhetsnivå. För att göra detta analyserar vi överlappningen mellan de förutspådda utfallen och 60-dagarsfönstret före ett fel. Detta illustreras i följande figur, som visar fyra fall av att förutsäga utfall:

• Riktigt negativt – Alla förutsägelseresultat är negativa (lila) (Figur 5)
• Falskt positivt – De positiva förutsägelserna är falska larm (Figur 6)
• Falskt negativ – Även om alla förutsägelser är negativa kan de faktiska etiketterna vara positiva (gröna) (Figur 7)
• Riktigt positivt – Vissa av förutsägelserna kan vara negativa (gröna), och minst en förutsägelse är positiv (gul) (Figur 8)

Figur 5.1: Sant negativt fall	Figur 5.2: Falskt positivt fall
Figur 5.3: Falskt negativt fall	Figur 5.4: Sant positivt fall

Efter träning använder vi utvärderingsuppsättningen för att justera tröskeln för att skicka en varning. Att sätta modellens konfidensgräns på 0.99 ger en precision på ungefär 81 %. Detta faller under vårt ursprungliga 90%-kriterium för framgång. Vi fann dock att en stor del av enheterna misslyckades strax utanför 60-dagarsutvärderingsfönstret. Detta är vettigt, eftersom en enhet aktivt kan visa felaktigt beteende men det tar längre tid än 60 dagar att misslyckas. För att hantera detta definierade vi ett mått som heter effektiv precision, vilket är en kombination av den sanna positiva precisionen (81 %) med den extra precisionen av lockouter som inträffade under de 30 dagarna efter vårt mål på 60 dagar.

För en VVS-återförsäljare är det viktigaste att en inspektion på plats hjälper till att förhindra framtida VVS-problem för kunden. Med denna modell uppskattar vi att 81.2 % av tiden inspektionen kommer att förhindra att en lockout inträffar under de närmaste 60 dagarna. Dessutom skulle 10.4 % av tiden lockouten ha inträffat inom 90 dagar efter inspektion. De återstående 8.4 % kommer att vara ett falskt larm. Den effektiva precisionen för den tränade modellen är 91.6%.

Slutsats

I det här inlägget visade vi hur vårt team använde AWS Glue och SageMaker för att skapa en skalbar övervakad inlärningslösning för prediktivt underhåll. Vår modell kan fånga trender över långtidshistorik av sensordata och noggrant detektera hundratals utrustningsfel veckor i förväg. Att förutsäga fel i förväg kommer att minska tiden från trottoarkant till trottoarkant, vilket gör det möjligt för våra återförsäljare att ge teknisk assistans i rätt tid och förbättra den övergripande kundupplevelsen. Effekterna av detta tillvägagångssätt kommer att växa över tiden eftersom fler molnanslutna HVAC-enheter installeras varje år.

Vårt nästa steg är att integrera dessa insikter i den kommande releasen av Carriers Connected Dealer Portal. Portalen kombinerar dessa prediktiva varningar med andra insikter vi får från vår AWS-baserade datasjö för att ge våra återförsäljare mer klarhet i utrustningens hälsa över hela deras kundbas. Vi kommer att fortsätta att förbättra vår modell genom att integrera data från ytterligare källor och extrahera mer avancerade funktioner från vår sensordata. Metoderna som används i detta projekt ger en stark grund för vårt team att börja svara på andra nyckelfrågor som kan hjälpa oss att minska garantianspråk och förbättra utrustningens effektivitet på fältet.

Om du vill ha hjälp med att påskynda användningen av ML i dina produkter och tjänster, vänligen kontakta Amazon ML Solutions Lab. För att lära dig mer om tjänsterna som används i detta projekt, se AWS Glue Developer Guide och Amazon SageMaker Developer Guide.

---

Om författarna

Ravi Patankar är en teknisk ledare för IoT-relaterad analys på Carrier's Residential HVAC Unit. Han formulerar analysproblem relaterade till diagnostik och prognostik och ger vägledning för ML/djupinlärningsbaserade analyslösningar och arkitektur.

Dan Volk är en dataforskare vid AWS Generative AI Innovation Center. Han har tio års erfarenhet av maskininlärning, djupinlärning och tidsserieanalys och har en magisterexamen i datavetenskap från UC Berkeley. Han brinner för att omvandla komplexa affärsutmaningar till möjligheter genom att utnyttja banbrytande AI-teknik.

Yingwei Yu är en tillämpad forskare vid AWS Generative AI Innovation Center. Han har erfarenhet av att arbeta med flera organisationer över branscher med olika proof-of-concepts inom maskininlärning, inklusive NLP, tidsserieanalys och generativ AI-teknik. Yingwei tog sin doktorsexamen i datavetenskap från Texas A&M University.

Yanxiang Yu är en tillämpad forskare på Amazon Web Services och arbetar på Generative AI Innovation Center. Med över 8 års erfarenhet av att bygga AI- och maskininlärningsmodeller för industriella applikationer, är han specialiserad på generativ AI, datorseende och tidsseriemodellering. Hans arbete fokuserar på att hitta innovativa sätt att tillämpa avancerade generativa tekniker på verkliga problem.

Diego Socolinsky är Senior Applied Science Manager med AWS Generative AI Innovation Center, där han leder leveransteamet för regionerna i östra USA och Latinamerika. Han har över tjugo års erfarenhet av maskininlärning och datorseende, och har en doktorsexamen i matematik från Johns Hopkins University.

Kexin Ding är en femteårs Ph.D. kandidat i datavetenskap vid UNC-Charlotte. Hennes forskning fokuserar på att tillämpa metoder för djupinlärning för att analysera multimodala data, inklusive medicinsk bild- och genomiksekvenseringsdata.

• SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
• PlatoData.Network Vertical Generative Ai. Styrka dig själv. Tillgång här.
• PlatoAiStream. Web3 Intelligence. Kunskap förstärkt. Tillgång här.
• Platoesg. Fordon / elbilar, Kol, CleanTech, Energi, Miljö, Sol, Avfallshantering. Tillgång här.
• PlatoHealth. Biotech och kliniska prövningar Intelligence. Tillgång här.
• ChartPrime. Höj ditt handelsspel med ChartPrime. Tillgång här.
• BlockOffsets. Modernisera miljökompensation ägande. Tillgång här.
• Källa: https://aws.amazon.com/blogs/machine-learning/how-carrier-predicts-hvac-faults-using-aws-glue-and-amazon-sagemaker/