Tilstandsbaseret vedligeholdelse: en praktisk guide for bygningsteams

Foto af TECNIC Bioprocess Solutions på Unsplash.

Tilstandsbaseret vedligeholdelse (CBM) er en vedligeholdelsespolitik, der udløser arbejde kun, når udstyrstilstandsdata siger, det er nødvendigt, ikke på en fast kalender, og ikke efter noget går i stykker. En vibrationsaflæsning krydser en tærskel, en lejetemperatur klatrer forbi sin baseline, en kompressors strømtræk driver ud af sit normale bånd, og det er, hvad der planlægger arbejdsordren, ikke den 90-dages kalenderpåmindelse i dit CMMS.

CBM sidder mellem to idéer, der bruges næsten synonymt, og det bør de ikke. Tilstandsovervågning er sensor- og datalaget, vibrationssensorerne, strømtransformerne og de termiske prober, der producerer aflæsningerne. Prædiktiv vedligeholdelse er modelleringslaget, statistikken eller machine learningen, der omdanner de aflæsninger til en prognose ("dette leje har omkring tre ugers nyttig levetid tilbage"). Tilstandsbaseret vedligeholdelse er ingen af disse. Det er politiklaget: reglen, der siger, at arbejde sker, når en tærskel krydses, uanset om den tærskel kommer fra en simpel alarmgrænse eller en prædiktiv models output. Du kan køre CBM med ikke mere sofistikeret end et regneark og en tærskel, du behøver ikke machine learning til det.

Det er også distinkt fra fejldetektion og diagnostik, som flager en specifik fejl, når den allerede er dukket op i dataene. FDD fortæller dig, hvad der er forkert; tilstandsbaseret vedligeholdelse er politikken, der beslutter, hvad der sker næste.

Tilstandsbaseret vedligeholdelse vs. prædiktiv vedligeholdelse vs. forebyggende vedligeholdelse

De tre strategier løser samme problem, at afgøre hvornår man skal gribe ind, med forskellige mængder data og forskellige risikoprofiler. Forebyggende vedligeholdelse er standarden, de fleste bygninger stadig kører; prædiktiv vedligeholdelse er den mest dataintensive; tilstandsbaseret vedligeholdelse sidder i mellem, og for meget bygningsudstyr er det den bedre afvejning.

Prædiktiv vedligeholdelse behøver svigthistorik at træne mod, og de fleste bygninger har ikke nok af det til andet end deres højst-værdi-aktiver. Tilstandsbaseret vedligeholdelse gør det ikke: en tærskel, du kan forsvare med en ingeniørs dømmekraft, er tilstrækkeligt til at starte.

Prædiktiv vedligeholdelse tilstandsovervågning: hvor de to overlapper

I praksis vælger de fleste modne programmer ikke en strategi og stopper, de lægger tilstandsbaseret vedligeholdelse under prædiktiv vedligeholdelse tilstandsovervågning, når de har nok sensorhistorik til at retfærdiggøre det ekstra modelleringsarbejde. Tilstandsovervågningslaget leverer det rå signal: vibrationsspektre, lejetemperaturtendenser, motorstrømsignaturer. En simpel tilstandsbaseret vedligeholdelsespolitik handler direkte på det signal, krydser tærsklen, åbner arbejdsordren. Et program for prædiktiv vedligeholdelse tilstandsovervågning går et skridt videre og fodrer samme signal ind i en model, der estimerer resterende nyttig levetid, så arbejdsordren bærer en tidsramme ("udskift inden 15 dage") frem for bare et flag.

Ingen erstatter den anden. CBM er, hvad de fleste teams bør køre først, fordi det ikke kræver et svigthistorik-datasæt. Prædiktiv modellering er opgraderingen, du tilføjer, når tilstandsdataen har strømmet lang tid nok til at træne mod.

Hvordan tilstandsbaseret vedligeholdelse fungerer

Et CBM-program har fire bevægelige dele, og bygningsteams, der springer direkte til at købe sensorer, sidder normalt fast ved trin tre.

• Instrumenter aktivet, vibration, temperatur, strøm, olieanalyse, eller trykaflæsere, valgt til de svigtmodes, der faktisk betyder noget for den udstyrstype.
• Sæt en baseline og en tærskel, hvordan ser "normal" ud for denne specifikke enhed, og hvor langt fra normal udløser handling? Producentspecifikationer er et startpunkt, ikke det endelige svar; en kølemaskine, der har kørt varm siden installation, har en anden "normal" end specifikationsbladet.
• Rut alarmen til en arbejdsordre automatisk, en tærskeloverskridelse, der lander i en indbakke, ingen læser, er ikke tilstandsbaseret vedligeholdelse, det er tilstandsovervågning med ekstra trin.
• Luk loopet, følg om interventionen faktisk forhindrede et svigt, og finjuster tærsklen. For sensitiv, og teknikere begynder at ignorere alarmer; for løs, og du er tilbage til kør-til-svigt.

Hvornår tilstandsbaseret vedligeholdelse er det rette valg, og hvornår det ikke er

CBM tjener sin plads på udstyr, hvor svigt er dyrt eller forstyrrende, men slitage er irregulær nok til, at en fast kalender enten spilder vedligeholdelsesbudget eller misser svigt. Kølemaskiner, kølertårne, store pumper og tag-enheder er de klassiske bygningskandidater, deres driftscyklusser varierer nok med vejr og belægning, at et kalenderbaseret interval er enten for konservativt (udskifter dele, der havde levetid tilbage) eller for aggressivt (misser en enhed, der har kørt hårdere end gennemsnit).

Det er en dårligere fit for udstyr, der er billigt at udskifte, redundant, eller fejler på måder, der ikke viser sig som en gradvis tendens, en lysarmatur eller en lavværdi-styreventil retfærdiggør ikke sensor- og overvågningsomkostningen. Og det er en dårligere fit for teams uden den operationelle disciplin til at handle på alarmer; en tærskel, ingen reagerer på i tre uger, sparer dig ingenting mod kalenderen, du udskiftede.

At bygge et tilstandsbaseret vedligeholdelsesprogram, der holder

De fleste CBM-udrulninger fejler på proces, ikke sensorer. Byggeordenen, der virker: start med de 10-20 aktiver, hvor uplanlagt nedetid er dyrest (mekaniske rum, ikke individuelle VAV-bokse), instrumenter kun dem, og bevis at tærskel-til-arbejdsordre-loopet lukker pålideligt, før du udvider. Et fejldetektion- og diagnostiklag er værd at tilføje, når det grundlæggende CBM-loop kører, FDD fanger fejl, tilstandsovervågning alene kan misse, som et fastklemt spjæld eller en fejlkalibreret sensor, og ruter dem ind i samme arbejdsordre-pipeline.

ROI for tilstandsbaseret vedligeholdelse: hvordan man retfærdiggør investeringen

Business case'et for CBM er sjældent "vi vil bruge mindre på vedligeholdelse", i det første år koster instrumentering og programopsætning ofte mere end den kalenderbaserede rutine, det erstatter. Sagen er undgået nedetid og undgået overvedligeholdelse, og begge behøver et tal tilknyttet, før nogen underskriver sensorer.

• Undgået uplanlagt nedetid, prissæt de sidste to eller tre uplanlagte svigt på udstyret, du målretter: tabte lejertimer, nødopkaldspræmier, hastefragt af dele. CBM eliminerer ikke svigt, men det gør de fleste af dem til planlagte reparationer med dele bestilt i forvejen.
• Undgået overvedligeholdelse, en kalenderbaseret PM-plan udskifter dele og drænder olie ved et fast interval uanset faktisk slitage. At trække vedligeholdelseslogget for udstyr, du er ved at instrumentere, viser normalt, at en betydelig andel af det forbrug var unødvendigt.
• Udvidet aktivlevetid, at fange et leje, der kører varmt, før det klemmer sig fast, beskytter motoren omkring det, ikke bare lejet. Den undgåede kapitaludskiftning er ofte den største linjepost, og den nemmeste at undervurdere.

De fleste teams starter ROI-sagen på en håndfuld aktiver, dem, der allerede optræder gentagne gange i uplanlagt-nedetid-logget, frem for at forsøge at modellere en portefølje-bred business case, før en enkelt sensor er installeret.

Almindelige fejl med tilstandsbaseret vedligeholdelse

• Instrumentering af alt på én gang, sensorer på lavværdi-udstyr genererer alarmvolumen uden proportional udbytte, og begraver alarmerne, der faktisk betyder noget, under støj.
• Brug af producenttærskler uden justering, en specifikationsbladets vibrationsgrænse antager en specifik installation og driftscyklus; et aktiv, der har kørt hårdere eller blødere end den antagelse, behøver sin egen baseline.
• At behandle en alarm som slutningen af workflowet, hvis en tærskeloverskridelse ikke automatisk opretter en arbejdsordre med en tekniker tildelt, er det tilstandsovervågning, ikke tilstandsbaseret vedligeholdelse.
• Aldrig at genbesøge tærskler, en tærskel sat én gang og aldrig finjusteret driver ud af relevans, når udstyret ældes; hvad talte som "normal" i år et af et aktivs liv er ikke "normal" i år otte.

Software til tilstandsbaseret vedligeholdelse: hvad det faktisk skal gøre

Du behøver ikke en fuld prædiktiv vedligeholdelsesplatform for at køre tilstandsbaseret vedligeholdelse, du behøver tre ting: en måde at indtage sensor- eller BMS-data, konfigurerbare tærskler pr. aktiv, og en arbejdsordre-integration, så et brud bliver til en udsendt tekniker uden et menneske i loopet. Nogle CMMS-platforme bolter dette på; nogle bygningsanalyseplatforme gør det nativt tværs af hvert udstyrsstykke, der læser ind i BMS'et, uden per-aktiv-konfiguration. Vi har sammenlignet de førende muligheder for software til tilstandsbaseret vedligeholdelse, inklusive hvor en snæver CMMS-tilføjelse er tilstrækkelig, og hvor du behøver en platform bygget til det, separat, da shortlisten afhænger stærkt af, hvor mange bygninger og BMS-leverandører du konsoliderer.

Ofte stillede spørgsmål

Hvad er tilstandsbaseret vedligeholdelse? En vedligeholdelsespolitik, der udløser arbejde baseret på real-time udstyrstilstandsdata, en tærskeloverskridelse i vibration, temperatur, eller strøm, frem for et fast kalenderinterval eller at vente på svigt.

Tilstandsbaseret vedligeholdelse vs. prædiktiv vedligeholdelse, hvad er forskellen? Tilstandsbaseret vedligeholdelse handler direkte på en tærskeloverskridelse i tilstandsdata. Prædiktiv vedligeholdelse lægger en statistisk eller machine learning-model på toppen af samme data for at forudsige et svigtvindue i forvejen. CBM er simplere at starte og kræver ikke svigthistorik; prædiktiv vedligeholdelse er mere præcis, men behøver mere data at træne mod.

Hvilke sensorer behøver tilstandsbaseret vedligeholdelse? Det afhænger af svigtmoden, du overvåger for, vibration og temperatursensorer for roterende udstyr som pumper og motorer, strømsensorer for elektriske belastninger, og olieanalyse for gearkasser og store kompressorer. De fleste bygningsteams starter med, hvad deres BMS allerede læser, før de tilføjer dedikerede sensorer.

Er tilstandsbaseret vedligeholdelse det samme som tilstandsovervågning? Nej. Tilstandsovervågning er sensor- og datalaget. Tilstandsbaseret vedligeholdelse er politikken, der beslutter, hvad der sker, når de data krydser en tærskel, tilstandsovervågning kan køre uden CBM tilknyttet, men CBM kan ikke køre uden nogen form for tilstandsovervågning, der fodrer det.

Hvilken software til tilstandsbaseret vedligeholdelse bør jeg bruge? Det afhænger af, om du forvalter en enkelt bygning eller en portefølje tværs af flere BMS-leverandører. Se vores sammenligning af de førende platforme for software til tilstandsbaseret vedligeholdelse for en opdeling.

Hvor meget koster det at starte et program for tilstandsbaseret vedligeholdelse? Omkostningen skalerer med, hvor meget du allerede læser ind i dit BMS mod hvor mange dedikerede sensorer du behøver at tilføje. Teams, der starter med de 10-20 aktiver, der allerede forårsager mest uplanlagt nedetid, og læner sig på eksisterende BMS-punkter, før de køber ny hardware, får et fungerende program live for en brøkdel af, hvad det ville koste at instrumentere en hel portefølje på forhånd.