Tilstandsbasert vedlikehold: en praktisk guide for byggteam

Foto av TECNIC Bioprocess Solutions på Unsplash.

Tilstandsbasert vedlikehold (CBM) er en vedlikeholdspolicy som utløser arbeid bare når utstyrets tilstandsdata sier det er nødvendig, ikke på en fast kalender, og ikke etter at noe går i stykker. En vibrasjonsavlesning krysser en terskel, en lagertemperatur klatrer forbi sin baseline, en kompressors strømtrekk driver ut av sitt normale bånd, og det er hva som planlegger arbeidsordren, ikke den 90-dagers kalenderpåminnelsen i CMMS-et ditt.

CBM sitter mellom to ideer som brukes nesten synonymt, og det bør de ikke. Tilstandsovervåking er sensor- og datalaget, vibrasjonssensorene, strømtransformatorene og de termiske proberne som produserer avlesningene. Prediktivt vedlikehold er modelleringslaget, statistikken eller maskinlæringen som gjør de avlesningene om til en prognose ("dette lageret har rundt tre uker nyttig levetid igjen"). Tilstandsbasert vedlikehold er ingen av disse. Det er policylaget: regelen som sier at arbeid skjer når en terskel krysses, uansett om den terskelen kommer fra en enkel alarmgrense eller en prediktiv modells output. Du kan kjøre CBM med ikke mer sofistikert enn et regneark og en terskel, du trenger ikke maskinlæring for å gjøre det.

Det er også distinkt fra feildeteksjon og diagnostikk, som flagger en spesifikk feil når den allerede har dukket opp i dataene. FDD forteller deg hva som er feil; tilstandsbasert vedlikehold er policyen som bestemmer hva som skjer neste.

Tilstandsbasert vedlikehold vs. prediktivt vedlikehold vs. forebyggende vedlikehold

De tre strategiene løser samme problem, å bestemme når man skal gripe inn, med forskjellige mengder data og forskjellige risikoprofiler. Forebyggende vedlikehold er standarden de fleste bygninger fortsatt kjører; prediktivt vedlikehold er det mest dataintensive; tilstandsbasert vedlikehold sitter i mellom, og for mye byggutstyr er det den bedre avveiningen.

Prediktivt vedlikehold trenger sviktshistorikk å trene mot, og de fleste bygninger har ikke nok av det for annet enn sine høyest-verdi-aktiva. Tilstandsbasert vedlikehold gjør ikke det: en terskel du kan forsvare med en ingeniørs vurdering, er nok til å starte.

Prediktivt vedlikehold tilstandsovervåking: der de to overlapper

I praksis velger de fleste modne programmer ikke én strategi og stopper der, de legger tilstandsbasert vedlikehold under prediktivt vedlikehold tilstandsovervåking når de har nok sensorhistorikk til å rettferdiggjøre det ekstra modelleringsarbeidet. Tilstandsovervåkingslaget leverer råsignalet: vibrasjonsspektre, lagertemperaturtrender, motorstrømsignaturer. En enkel tilstandsbasert vedlikeholdspolicy handler direkte på det signalet, kryss terskelen, åpne arbeidsordren. Et prediktivt vedlikehold tilstandsovervåkingsprogram går et skritt videre og mater samme signal inn i en modell som estimerer gjenværende nyttig levetid, slik at arbeidsordren bærer en tidsramme ("erstatt innen 15 dager") i stedet for bare et flagg.

Ingen erstatter den andre. CBM er hva de fleste team bør kjøre først, fordi det ikke krever et sviktshistorikk- datasett. Prediktiv modellering er oppgraderingen du legger til når tilstandsdataene har strømmet lenge nok til å trene mot.

Hvordan tilstandsbasert vedlikehold fungerer

Et CBM-program har fire bevegelige deler, og byggteam som hopper rett til å kjøpe sensorer, sitter vanligvis fast ved trinn tre.

• Instrumenter aktivumet, vibrasjon, temperatur, strøm, oljeanalyse, eller trykksensorer, valgt for de sviktmodusene som faktisk betyr noe for den utstyrstypen.
• Sett en baseline og en terskel, hvordan ser "normal" ut for denne spesifikke enheten, og hvor langt fra normal utløser handling? Produsentspesifikasjoner er et utgangspunkt, ikke det endelige svaret; en kjølemaskin som har gått varm siden installasjon, har en annen "normal" enn spesifikasjonsbladet.
• Rut varselet til en arbeidsordre automatisk, en terskeloverskridelse som lander i en innboks ingen leser, er ikke tilstandsbasert vedlikehold, det er tilstandsovervåking med ekstra steg.
• Lukk loopen, spor om intervensjonen faktisk forhindret en svikt, og finjuster terskelen. For sensitiv, og teknikere begynner å ignorere varsler; for løs, og du er tilbake til kjør-til-svikt.

Når tilstandsbasert vedlikehold er det rette valget, og når det ikke er

CBM tjener sin plass på utstyr der svikt er kostbart eller forstyrrende, men slitasjen er irregulær nok til at en fast kalender enten sløser vedlikeholdsbudsjett eller går glipp av svikt. Kjølemaskiner, kjøletårn, store pumper og takenheter er de klassiske byggkandidatene, driftssyklusene deres varierer nok med vær og belegg at et kalenderbasert intervall enten er for konservativt (erstatter deler som hadde levetid igjen) eller for aggressivt (går glipp av en enhet som har gått hardere enn gjennomsnittet).

Det er en dårligere match for utstyr som er billig å erstatte, redundant, eller svikter på måter som ikke viser seg som en gradvis trend, en lysarmatur eller en lavverdi-styreventil rettferdiggjør ikke sensor- og overvåkingskostnaden. Og det er en dårligere match for team uten den operative disiplinen til å handle på varsler; en terskel ingen svarer på i tre uker, sparer deg ingenting mot kalenderen du erstattet.

Å bygge et tilstandsbasert vedlikeholdsprogram som holder

De fleste CBM-utrullinger mislykkes på prosess, ikke sensorer. Byggeordenen som fungerer: start med de 10–20 aktiva der uplanlagt nedetid er dyrest (maskinrom, ikke individuelle VAV-bokser), instrumenter bare dem, og bevis at terskel-til-arbeidsordre-loopen lukker pålitelig før du utvider. Et feildeteksjons- og diagnostikklag er verdt å legge til når den grunnleggende CBM-loopen kjører, FDD fanger feil tilstandsovervåking alene kan gå glipp av, som et fastlåst spjeld eller en feilkalibrert sensor, og ruter dem inn i samme arbeidsordre-pipeline.

ROI for tilstandsbasert vedlikehold: hvordan rettferdiggjøre investeringen

Business casen for CBM er sjelden "vi vil bruke mindre på vedlikehold", i det første året kostner instrumentering og programoppsett ofte mer enn den kalenderbaserte rutinen det erstatter. Saken er unngått nedetid og unngått overvedlikehold, og begge trenger et tall festet ved før noen signerer på sensorer.

• Unngått uplanlagt nedetid, sett en pris på de siste to eller tre uplanlagte sviktene på utstyret du retter deg mot: tapte leietakertimer, nødtilkallingspremier, ekspress fraktkostnader for deler. CBM eliminerer ikke svikt, men det gjør de fleste av dem om til planlagte reparasjoner med deler bestilt på forhånd.
• Unngått overvedlikehold, en kalenderbasert PM-plan erstatter deler og tapper olje ved et fast intervall uavhengig av faktisk slitasje. Å trekke vedlikeholdsloggen for utstyr du er i ferd med å instrumentere, viser vanligvis at en betydelig andel av det forbruket var unødvendig.
• Utvidet aktivumlevetid, å fange et lager som går varmt før det låser seg, beskytter motoren rundt det, ikke bare lageret. Den unngåtte kapitalutskiftningen er ofte den største linjeposten, og den lettest å undervurdere.

De fleste team starter ROI-saken på et håndfull aktiva, de som allerede dukker opp gjentatte ganger i uplanlagt-nedetid-loggen, i stedet for å forsøke å modellere en porteføljeomfattende business case før en enkelt sensor er installert.

Vanlige feil med tilstandsbasert vedlikehold

• Instrumentering av alt samtidig, sensorer på lavverdi-utstyr genererer varselvolum uten proporsjonal utbytte, og begraver varslene som faktisk betyr noe, under støy.
• Bruk av produsentterskler uten justering, en spesifikasjonsbladets vibrasjonsgrense antar en spesifikk installasjon og driftssyklus; et aktivum som har gått hardere eller mildere enn den antakelsen, trenger sin egen baseline.
• Å behandle et varsel som slutten av arbeidsflyten, hvis en terskeloverskridelse ikke automatisk skaper en arbeidsordre med en tekniker tildelt, er det tilstandsovervåking, ikke tilstandsbasert vedlikehold.
• Aldri å revidere terskler, en terskel satt én gang og aldri finjustert driver ut av relevans når utstyret eldes; hva som gjaldt som "normalt" i år én av et aktivums liv, er ikke "normalt" i år åtte.

Programvare for tilstandsbasert vedlikehold: hva den faktisk må gjøre

Du trenger ikke en full plattform for prediktivt vedlikehold for å kjøre tilstandsbasert vedlikehold, du trenger tre ting: en måte å ta inn sensor- eller BMS-data, konfigurerbare terskler per aktivum, og en arbeidsordre-integrasjon slik at et brudd blir en utsendt tekniker uten et menneske i loopen. Noen CMMS-plattformer bolter dette på; noen bygganalyseplattformer gjør det nativt over hvert utstyrsstykke som leser inn i BMS-et, uten per-aktivum-konfigurasjon. Vi har sammenlignet de ledende alternativene for programvare for tilstandsbasert vedlikehold, inkludert hvor et smalt CMMS-tillegg er tilstrekkelig og hvor du trenger en plattform bygget for det, separat, siden kortlisten avhenger sterkt av hvor mange bygninger og BMS-leverandører du konsoliderer.

Ofte stilte spørsmål

Hva er tilstandsbasert vedlikehold? En vedlikeholdspolicy som utløser arbeid basert på sanntids utstyrstilstandsdata, en terskeloverskridelse i vibrasjon, temperatur, eller strøm, i stedet for et fast kalenderintervall eller å vente på svikt.

Tilstandsbasert vedlikehold vs. prediktivt vedlikehold, hva er forskjellen? Tilstandsbasert vedlikehold handler direkte på en terskeloverskridelse i tilstandsdata. Prediktivt vedlikehold legger en statistisk eller maskinlæringsmodell på toppen av samme data for å forutsi et sviktvindu i forkant. CBM er enklere å starte og krever ikke sviktshistorikk; prediktivt vedlikehold er mer presist, men trenger mer data å trene mot.

Hvilke sensorer trenger tilstandsbasert vedlikehold? Det kommer an på sviktmodusen du overvåker for, vibrasjon og temperatursensorer for roterende utstyr som pumper og motorer, strømsensorer for elektriske belastninger, og oljeanalyse for gearkasser og store kompressorer. De fleste byggteam starter med det BMS-et allerede leser, før de legger til dedikerte sensorer.

Er tilstandsbasert vedlikehold det samme som tilstandsovervåking? Nei. Tilstandsovervåking er sensor- og datalaget. Tilstandsbasert vedlikehold er policyen som bestemmer hva som skjer når de dataene krysser en terskel, tilstandsovervåking kan kjøre uten CBM tilknyttet, men CBM kan ikke kjøre uten noen form for tilstandsovervåking som mater det.

Hvilken programvare for tilstandsbasert vedlikehold bør jeg bruke? Det kommer an på om du forvalter en enkelt bygning eller en portefølje over flere BMS-leverandører. Se vår sammenligning av de ledende plattformene for programvare for tilstandsbasert vedlikehold for en oversikt.

Hvor mye kostner det å starte et program for tilstandsbasert vedlikehold? Kostnaden skalerer med hvor mye du allerede leser inn i BMS-et ditt mot hvor mange dedikerte sensorer du trenger å legge til. Team som starter med de 10–20 aktivaene som allerede forårsaker mest uplanlagt nedetid, og lener seg på eksisterende BMS-punkter før de kjøper ny maskinvare, får et fungerende program live for en brøkdel av hva det ville kostet å instrumentere en hel portefølje på forhånd.