Hvordan Carrier forutsier HVAC-feil ved hjelp av AWS Glue og Amazon SageMaker | Amazon Web Services

Med deres egne ord, "I 1902 løste Willis Carrier en av menneskehetens mest unnvikende utfordringer med å kontrollere innemiljøet gjennom moderne klimaanlegg. I dag skaper Carrier-produkter komfortable miljøer, ivaretar den globale matforsyningen og muliggjør sikker transport av viktige medisinske forsyninger under krevende forhold."

At Carrier, grunnlaget for vår suksess er å lage produkter som våre kunder kan stole på for å holde dem komfortable og trygge året rundt. Høy pålitelighet og lav nedetid for utstyr blir stadig viktigere ettersom ekstreme temperaturer blir mer vanlig på grunn av klimaendringer. Vi har historisk sett vært avhengige av terskelbaserte systemer som varsler oss om unormal utstyrsatferd, ved å bruke parametere definert av ingeniørteamet vårt. Selv om slike systemer er effektive, er de ment å identifisere og diagnostisere utstyrsproblemer i stedet for å forutsi dem. Ved å forutsi feil før de oppstår, kan våre HVAC-forhandlere proaktivt løse problemer og forbedre kundeopplevelsen.

For å forbedre utstyrets pålitelighet, samarbeidet vi med Amazon Machine Learning Solutions Lab å utvikle en tilpasset maskinlæringsmodell (ML) som er i stand til å forutsi utstyrsproblemer før feil. Teamene våre utviklet et rammeverk for å behandle over 50 TB med historiske sensordata og forutsi feil med 91 % presisjon. Vi kan nå varsle forhandlere om forestående utstyrssvikt, slik at de kan planlegge inspeksjoner og minimere nedetid for enheten. Løsningsrammeverket er skalerbart ettersom mer utstyr er installert og kan gjenbrukes til en rekke nedstrøms modelleringsoppgaver.

I dette innlegget viser vi hvordan Carrier- og AWS-teamene brukte ML for å forutsi feil på tvers av store utstyrsflåter ved å bruke en enkelt modell. Vi fremhever først hvordan vi bruker AWS Lim for svært parallell databehandling. Så diskuterer vi hvordan Amazon SageMaker hjelper oss med funksjonsutvikling og å bygge en skalerbar overvåket dyplæringsmodell.

Oversikt over brukstilfeller, mål og risikoer

Hovedmålet med dette prosjektet er å redusere nedetid ved å forutsi forestående utstyrsfeil og varsle forhandlere. Dette lar forhandlere planlegge vedlikehold proaktivt og yte eksepsjonell kundeservice. Vi møtte tre hovedutfordringer når vi arbeidet med denne løsningen:

• Dataskalerbarhet – Databehandling og funksjonsutvinning må skaleres på tvers av store voksende historiske sensordata
• Modellens skalerbarhet – Modelleringstilnærmingen må være i stand til å skalere over over 10,000 XNUMX enheter
• Modellpresisjon – Lave falske positiver er nødvendig for å unngå unødvendige vedlikeholdsinspeksjoner

Skalerbarhet, både fra et data- og modelleringsperspektiv, er et nøkkelkrav for denne løsningen. Vi har over 50 TB med historiske utstyrsdata og forventer at disse dataene vil vokse raskt etter hvert som flere HVAC-enheter kobles til skyen. Databehandling og modellslutninger må skaleres etter hvert som dataene våre vokser. For at vår modelleringstilnærming skal skalere over over 10,000 XNUMX enheter, trenger vi en modell som kan lære av en flåte av utstyr i stedet for å stole på unormale avlesninger for en enkelt enhet. Dette vil tillate generalisering på tvers av enheter og redusere kostnadene ved slutning ved å være vert for en enkelt modell.

Den andre bekymringen for denne brukssaken er å utløse falske alarmer. Dette betyr at en forhandler eller tekniker vil gå på stedet for å inspisere kundens utstyr og finne at alt fungerer som det skal. Løsningen krever en modell med høy presisjon for å sikre at når en forhandler blir varslet, er det sannsynlig at utstyret svikter. Dette bidrar til å tjene tilliten til både forhandlere, teknikere og huseiere, og reduserer kostnadene forbundet med unødvendige inspeksjoner på stedet.

Vi samarbeidet med AI/ML-ekspertene ved Amazon ML Solutions Lab for en 14-ukers utviklingsinnsats. Til slutt inkluderer løsningen vår to hovedkomponenter. Den første er en databehandlingsmodul bygget med AWS Glue som oppsummerer utstyrsatferd og reduserer størrelsen på treningsdataene våre for effektiv nedstrømsbehandling. Den andre er et modelltreningsgrensesnitt administrert gjennom SageMaker, som lar oss trene, tune og evaluere modellen vår før den distribueres til et produksjonsendepunkt.

Databehandling

Hver HVAC-enhet vi installerer genererer data fra 90 forskjellige sensorer med avlesninger for turtall, temperatur og trykk i hele systemet. Dette utgjør omtrent 8 millioner datapunkter generert per enhet per dag, med titusenvis av enheter installert. Ettersom flere HVAC-systemer er koblet til skyen, forventer vi at volumet av data vil vokse raskt, noe som gjør det avgjørende for oss å administrere størrelsen og kompleksiteten for bruk i nedstrømsoppgaver. Lengden på sensordatahistorikken utgjør også en modelleringsutfordring. En enhet kan begynne å vise tegn på forestående feil måneder før en feil faktisk utløses. Dette skaper et betydelig etterslep mellom det prediktive signalet og den faktiske feilen. En metode for å komprimere lengden på inngangsdataene blir kritisk for ML-modellering.

For å adressere størrelsen og kompleksiteten til sensordataene komprimerer vi dem til syklusfunksjoner som vist i figur 1. Dette reduserer datastørrelsen dramatisk samtidig som vi fanger opp funksjoner som karakteriserer utstyrets oppførsel.

AWS Glue er en serverløs dataintegrasjonstjeneste for behandling av store mengder data i stor skala. AWS Glue tillot oss enkelt å kjøre parallell dataforbehandling og funksjonsutvinning. Vi brukte AWS Glue til å oppdage sykluser og oppsummere enhetens oppførsel ved å bruke nøkkelfunksjoner identifisert av ingeniørteamet vårt. Dette reduserte størrelsen på datasettet vårt dramatisk fra over 8 millioner datapunkter per dag per enhet ned til omtrent 1,200. Det er avgjørende at denne tilnærmingen bevarer prediktiv informasjon om enhetens oppførsel med et mye mindre datafotavtrykk.

Utdataene fra AWS Glue-jobben er et sammendrag av enhetens oppførsel for hver syklus. Vi bruker da en Amazon SageMaker-prosessering jobb med å beregne funksjoner på tvers av sykluser og merke dataene våre. Vi formulerer ML-problemet som en binær klassifiseringsoppgave med et mål om å forutsi utstyrsfeil i løpet av de neste 60 dagene. Dette gjør at forhandlernettverket vårt kan rette opp potensielle utstyrsfeil i tide. Det er viktig å merke seg at ikke alle enheter feiler innen 60 dager. En enhet som opplever langsom ytelsesforringelse kan ta lengre tid før den mislykkes. Vi tar opp dette under modellevalueringstrinnet. Vi fokuserte vår modellering på sommeren fordi de månedene er når de fleste HVAC-systemer i USA er i konsekvent drift og under mer ekstreme forhold.

Modellering

Transformatorarkitekturer har blitt den nyeste tilnærmingen for håndtering av tidsdata. De kan bruke lange sekvenser av historiske data ved hvert tidstrinn uten å lide av forsvinnende gradienter. Inndataene til modellen vår på et gitt tidspunkt er sammensatt av funksjonene for de foregående 128 utstyrssyklusene, som er omtrent en ukes drift av enheten. Dette behandles av en tre-lags koder hvis utgang beregnes som gjennomsnitt og mates inn i en multi-layered perceptron (MLP) klassifikator. MLP-klassifikatoren er sammensatt av tre lineære lag med ReLU-aktiveringsfunksjoner og et siste lag med LogSoftMax-aktivering. Vi bruker vektet negativ log-sannsynlighetstap med en annen vekt på den positive klassen for tapsfunksjonen vår. Dette gir modellen vår mot høy presisjon og unngår kostbare falske alarmer. Den inkorporerer også forretningsmålene våre direkte i modellopplæringsprosessen. Figur 2 illustrerer transformatorarkitekturen.

Kurs

En utfordring når man trener denne tidsmessige læringsmodellen er dataubalanse. Noen enheter har lengre driftshistorikk enn andre og har derfor flere sykluser i vårt datasett. Fordi de er overrepresentert i datasettet, vil disse enhetene ha større innflytelse på modellen vår. Vi løser dette ved å ta et tilfeldig utvalg av 100 sykluser i en enhets historie hvor vi vurderer sannsynligheten for feil på det tidspunktet. Dette sikrer at hver enhet er likt representert under opplæringsprosessen. Mens du fjerner problemet med ubalanserte data, har denne tilnærmingen den ekstra fordelen av å replikere en batchbehandlingsmetode som vil bli brukt i produksjonen. Denne prøvetakingsmetoden ble brukt på trenings-, validerings- og testsettene.

Trening ble utført ved hjelp av en GPU-akselerert forekomst på SageMaker. Overvåking av tapet viser at den oppnår de beste resultatene etter 180 treningsepoker som vist i figur 3. Figur 4 viser at arealet under ROC-kurven for den resulterende tidsklassifiseringsmodellen er 81 %.

Figur 3: Treningstap over epoker

Figur 4: ROC-AUC for 60-dagers lockout

Evaluering

Mens vår modell er trent på syklusnivå, må evaluering foregå på enhetsnivå. På denne måten blir en enhet med flere sanne positive deteksjoner fortsatt kun regnet som en enkelt sann positiv på enhetsnivå. For å gjøre dette analyserer vi overlappingen mellom de forutsagte resultatene og 60-dagers vinduet før en feil. Dette er illustrert i følgende figur, som viser fire tilfeller av å forutsi utfall:

• Ekte negativt – Alle prediksjonsresultatene er negative (lilla) (Figur 5)
• Falsk positiv – De positive spådommene er falske alarmer (Figur 6)
• Falske negative – Selv om spådommene alle er negative, kan de faktiske etikettene være positive (grønne) (Figur 7)
• Riktig positiv – Noen av spådommene kan være negative (grønne), og minst én prediksjon er positiv (gul) (Figur 8)

Figur 5.1: Ekte negativ kasus	Figur 5.2: Falsk positiv sak
Figur 5.3: Falsk negativ sak	Figur 5.4: Sant positivt tilfelle

Etter trening bruker vi evalueringssettet til å justere terskelen for å sende et varsel. Å sette modellens konfidensgrense til 0.99 gir en presisjon på omtrent 81 %. Dette er kortere enn vårt opprinnelige 90 %-kriterium for suksess. Vi fant imidlertid at en god del av enhetene mislyktes like utenfor 60-dagers evalueringsvinduet. Dette er fornuftig, fordi en enhet aktivt kan vise feil oppførsel, men det tar mer enn 60 dager å mislykkes. For å håndtere dette definerte vi en beregning kalt effektiv presisjon, som er en kombinasjon av den sanne positive presisjonen (81 %) med den ekstra presisjonen til lockouts som skjedde i løpet av de 30 dagene utover vårt mål på 60-dagers vindu.

For en VVS-forhandler er det viktigste at en inspeksjon på stedet bidrar til å forhindre fremtidige VVS-problemer for kunden. Ved å bruke denne modellen anslår vi at 81.2 % av tiden inspeksjonen vil forhindre at en lockout oppstår i løpet av de neste 60 dagene. I tillegg ville 10.4 % av tiden lockouten har skjedd innen 90 dager etter inspeksjon. De resterende 8.4 % vil være en falsk alarm. Den effektive presisjonen til den trente modellen er 91.6 %.

konklusjonen

I dette innlegget viste vi hvordan teamet vårt brukte AWS Glue og SageMaker for å lage en skalerbar veiledet læringsløsning for prediktivt vedlikehold. Vår modell er i stand til å fange opp trender på tvers av langsiktige historier av sensordata og nøyaktig oppdage hundrevis av utstyrsfeil uker i forveien. Forutsigelse av feil på forhånd vil redusere fortauskant-til-fortaus-tid, slik at våre forhandlere kan gi mer rettidig teknisk assistanse og forbedre den generelle kundeopplevelsen. Virkningene av denne tilnærmingen vil vokse over tid ettersom flere skytilkoblede HVAC-enheter installeres hvert år.

Vårt neste skritt er å integrere denne innsikten i den kommende utgivelsen av Carriers Connected Dealer Portal. Portalen kombinerer disse prediktive varslene med annen innsikt vi henter fra vår AWS-baserte datainnsjø for å gi våre forhandlere mer klarhet i utstyrshelsen på tvers av hele kundebasen. Vi vil fortsette å forbedre modellen vår ved å integrere data fra flere kilder og trekke ut mer avanserte funksjoner fra sensordataene våre. Metodene som brukes i dette prosjektet gir et sterkt grunnlag for teamet vårt til å begynne å svare på andre nøkkelspørsmål som kan hjelpe oss med å redusere garantikrav og forbedre utstyrseffektiviteten i felten.

Hvis du vil ha hjelp til å akselerere bruken av ML i produktene og tjenestene dine, kan du kontakte Amazon ML Solutions Lab. For å lære mer om tjenestene som brukes i dette prosjektet, se AWS Glue Developer Guide og Amazon SageMaker utviklerveiledning.

---

Om forfatterne

Ravi Patankar er en teknisk leder for IoT-relatert analyse ved Carrier's Residential HVAC Unit. Han formulerer analyseproblemer knyttet til diagnostikk og prognoser og gir retning for ML/deep learning-baserte analyseløsninger og arkitektur.

Dan Volk er dataforsker ved AWS Generative AI Innovation Center. Han har ti års erfaring innen maskinlæring, dyp læring og tidsserieanalyse og har en mastergrad i datavitenskap fra UC Berkeley. Han brenner for å transformere komplekse forretningsutfordringer til muligheter ved å utnytte banebrytende AI-teknologier.

Yingwei Yu er en Applied Scientist ved AWS Generative AI Innovation Center. Han har erfaring med å jobbe med flere organisasjoner på tvers av bransjer på ulike proof-of-concepts innen maskinlæring, inkludert NLP, tidsserieanalyse og generative AI-teknologier. Yingwei fikk sin doktorgrad i informatikk fra Texas A&M University.

Yanxiang Yu er en Applied Scientist hos Amazon Web Services, og jobber med Generative AI Innovation Center. Med over 8 års erfaring med å bygge AI og maskinlæringsmodeller for industrielle applikasjoner, spesialiserer han seg på generativ AI, datasyn og tidsseriemodellering. Arbeidet hans fokuserer på å finne innovative måter å bruke avanserte generative teknikker på problemer i den virkelige verden.

Diego Socolinsky er Senior Applied Science Manager ved AWS Generative AI Innovation Center, hvor han leder leveringsteamet for regionene i Øst-USA og Latin-Amerika. Han har over tjue års erfaring innen maskinlæring og datasyn, og har en doktorgrad i matematikk fra Johns Hopkins University.

Kexin Ding er en femteårs Ph.D. kandidat i informatikk ved UNC-Charlotte. Forskningen hennes fokuserer på å bruke dyplæringsmetoder for å analysere multimodale data, inkludert medisinsk bilde- og genomikk-sekvenseringsdata.

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• PlatoData.Network Vertical Generative Ai. Styrk deg selv. Tilgang her.
• PlatoAiStream. Web3 Intelligence. Kunnskap forsterket. Tilgang her.
• PlatoESG. Bil / elbiler, Karbon, CleanTech, Energi, Miljø, Solenergi, Avfallshåndtering. Tilgang her.
• PlatoHelse. Bioteknologisk og klinisk etterretning. Tilgang her.
• ChartPrime. Hev handelsspillet ditt med ChartPrime. Tilgang her.
• BlockOffsets. Modernisering av eierskap for miljøkompensasjon. Tilgang her.
• kilde: https://aws.amazon.com/blogs/machine-learning/how-carrier-predicts-hvac-faults-using-aws-glue-and-amazon-sagemaker/