Tillståndsbaserat underhåll: en praktisk guide för fastighetsteam

Foto av TECNIC Bioprocess Solutions på Unsplash.

Tillståndsbaserat underhåll (CBM) är en underhållspolicy som utlöser arbete endast när tillståndsdata från utrustningen säger att det behövs, inte enligt en fast kalender och inte efter att något har gått sönder. En vibrationsavläsning korsar ett tröskelvärde, en lagertemperatur klättrar förbi sin baslinje, en kompressors strömförbrukning glider ur sitt normala band, och det är vad som schemalägger arbetsordern, inte 90-dagarspåminnelsen i ditt CMMS.

CBM sitter mellan två idéer som används nästan utbytbart, och det borde de inte göra. Tillståndsövervakning är sensor- och datalagret, vibrationssensorerna, strömtransformatorerna och de termiska sonderna som producerar avläsningarna. Prediktivt underhåll är modelleringslagret, statistiken eller maskininlärningen som omvandlar dessa avläsningar till en prognos ("detta lager har ungefär tre veckors användbar livslängd kvar"). Tillståndsbaserat underhåll är inget av detta. Det är policylagret: regeln som säger att arbete sker när ett tröskelvärde korsas, oavsett om det tröskelvärdet kommer från en enkel larmgräns eller resultatet av en prediktiv modell. Du kan köra CBM med inget mer sofistikerat än ett kalkylblad och ett tröskelvärde, du behöver inte maskininlärning för att göra det.

Det skiljer sig också från feldetektering och diagnostik, som flaggar ett specifikt fel när det redan har dykt upp i data. FDD berättar vad som är fel, tillståndsbaserat underhåll är policyn som bestämmer vad som händer härnäst.

Tillståndsbaserat underhåll jämfört med prediktivt underhåll jämfört med förebyggande underhåll

De tre strategierna löser samma problem, att bestämma när man ska ingripa, med olika mängder data och olika riskprofiler. Förebyggande underhåll är standarden som de flesta byggnader fortfarande kör. Prediktivt underhåll är det mest datatunga. Tillståndsbaserat underhåll sitter mittemellan, och för mycket byggnadsutrustning är det den bättre avvägningen.

Prediktivt underhåll behöver felhistorik att träna mot, och de flesta byggnader har inte tillräckligt av det för mer än sina högst värderade objekt. Tillståndsbaserat underhåll gör det inte: ett tröskelvärde du kan försvara med en ingenjörs bedömning är tillräckligt för att komma igång.

Prediktivt underhåll och tillståndsövervakning: var de två överlappar

I praktiken väljer de flesta mogna program inte en strategi och slutar där, de lägger tillståndsbaserat underhåll under prediktivt underhåll med tillståndsövervakning så snart de har tillräckligt med sensorhistorik för att motivera det extra modelleringsarbetet. Tillståndsövervakningslagret levererar rå signal: vibrationsspektra, lagertemperaturtrender, motorströmssignaturer. En enkel policy för tillståndsbaserat underhåll agerar direkt på den signalen, korsa tröskelvärdet, öppna arbetsordern. Ett program för prediktivt underhåll med tillståndsövervakning går ett steg längre och matar samma signal in i en modell som uppskattar kvarvarande användbar livslängd, så att arbetsordern får en tidsram ("byt inom 15 dagar") istället för bara en flagga.

Ingen ersätter den andra. CBM är vad de flesta team bör köra först, eftersom det inte kräver ett datasätt med felhistorik. Prediktiv modellering är uppgraderingen du lägger till när tillståndsdata har flödat länge nog att träna mot.

Hur tillståndsbaserat underhåll fungerar

Ett CBM-program har fyra rörliga delar, och fastighetsteam som hoppar direkt till att köpa sensorer fastnar vanligtvis vid steg tre.

• Instrumentera tillgången, vibrations-, temperatur-, ström-, oljeanalys- eller tryckgivare, valda för de felmoder som faktiskt betyder något för den utrustningstypen.
• Sätt en baslinje och ett tröskelvärde, hur ser "normalt" ut för denna specifika enhet, och hur långt från normalt utlöser åtgärd? Tillverkarens specifikationer är en utgångspunkt, inte det slutliga svaret; en kylmaskin som körts varm sedan installationen har ett annat "normalt" än specifikationsbladet.
• Dirigera larmet till en arbetsorder automatiskt, en tröskelöverskridning som hamnar i en inkorg ingen läser är inte tillståndsbaserat underhåll, det är tillståndsövervakning med extra steg.
• Slut slingan, spåra om ingreppet faktiskt förhindrade ett fel, och finjustera tröskelvärdet. Är det för känsligt börjar tekniker ignorera larm; är det för löst är du tillbaka till drift till fel.

När tillståndsbaserat underhåll är rätt val, och när det inte är det

CBM tjänar sitt uppehälle på utrustning där fel är kostsamma eller störande, men slitaget är oregelbundet nog att en fast kalender antingen slösar underhållsbudget eller missar fel. Kylmaskiner, kyltorn, stora pumpar och takmonterade enheter är de klassiska byggnadskandidaterna, deras driftcykler varierar tillräckligt med väder och beläggning att ett kalenderbaserat intervall antingen är för konservativt (byter delar som hade liv kvar) eller för aggressivt (missar en enhet som körts hårdare än genomsnittet).

Det är en sämre passform för utrustning som är billig att byta, redundant eller går sönder på sätt som inte visar sig som en gradvis trend, en armatur eller en lågvärdesventil motiverar inte sensor- och övervakningskostnaden. Och det är en sämre passform för team utan den operativa disciplinen att agera på larm; ett tröskelvärde som ingen svarar på under tre veckor sparar dig inget jämfört med kalendern det ersatte.

Att bygga ett tillståndsbaserat underhållsprogram som håller

De flesta CBM-utrullningar misslyckas på process, inte sensorer. Byggordningen som fungerar: börja med de 10 till 20 objekten där oplanerat driftstopp är dyrast (maskinrum, inte enskilda VAV-boxar), instrumentera bara dessa, och bevisa att tröskel-till-arbetsorder-slingan sluter tillförlitligt innan du expanderar. Ett lager av feldetektering och diagnostik är värt att lägga till när den grundläggande CBM-slingan körs, FDD fångar fel som tillståndsövervakning ensamt kan missa, som ett fastnat spjäll eller en felkalibrerad sensor, och dirigerar dem in i samma arbetsorderpipeline.

Avkastning på tillståndsbaserat underhåll: hur man motiverar investeringen

Affärscasen för CBM är sällan "vi kommer att spendera mindre på underhåll", under första året kostar ofta instrumentering och programuppsättning mer än den kalenderbaserade rutin den ersätter. Casen är undvikna driftstopp och undvikt överunderhåll, och båda behöver ett tal knutet till dem innan någon skriver på för sensorer.

• Undvikna oplanerade driftstopp, prissätt de senaste två eller tre oplanerade felen på utrustningen du riktar in dig på: förlorade hyresgästtimmar, premietillägg för akututryckningar, expressfrakt av delar. CBM eliminerar inte fel, men det omvandlar de flesta av dem till planerade reparationer med delar beställda i förväg.
• Undvikt överunderhåll, ett kalenderbaserat PM-schema byter delar och tömmer olja på ett fast intervall oavsett faktiskt slitage. Att dra fram underhållsloggen för utrustning du håller på att instrumentera visar vanligtvis att en betydande andel av den kostnaden var onödig.
• Förlängd livslängd på tillgången, att fånga ett lager som går varmt innan det låser sig skyddar motorn runt det, inte bara lagret. Den undvikna kapitalersättningen är ofta den största posten, och den lättaste att underskatta.

De flesta team börjar ROI-casen på ett fåtal objekt, de som redan dyker upp gång på gång i loggen för oplanerade driftstopp, snarare än att försöka modellera ett portföljomfattande affärscase innan en enda sensor är installerad.

Vanliga misstag med tillståndsbaserat underhåll

• Instrumentera allt på en gång, sensorer på lågvärdesutrustning genererar larmvolym utan proportionell utdelning, och begraver larmen som faktiskt betyder något under brus.
• Använda tillverkarens tröskelvärden utan att justera dem, en gräns för vibration från specifikationsbladet antar en specifik installation och driftcykel; en tillgång som körts hårdare eller mjukare än det antagandet behöver sin egen baslinje.
• Behandla ett larm som slutet av arbetsflödet, om en tröskelöverskridning inte automatiskt skapar en arbetsorder med en tekniker tilldelad, är det tillståndsövervakning, inte tillståndsbaserat underhåll.
• Aldrig återbesöka tröskelvärden, ett tröskelvärde satt en gång och aldrig finjusterat glider ur relevans när utrustningen åldras; vad som räknades som "normalt" i år ett av en tillgångs liv är inte "normalt" i år åtta.

Programvara för tillståndsbaserat underhåll: vad den faktiskt behöver göra

Du behöver inte en fullständig plattform för prediktivt underhåll för att köra tillståndsbaserat underhåll, du behöver tre saker: ett sätt att ta in sensor- eller BMS-data, konfigurerbara tröskelvärden per tillgång och en arbetsorderintegration så att en överskridning blir en utskickad tekniker utan en människa i slingan. Vissa CMMS-plattformar bygger på detta; vissa fastighetsanalysplattformar gör det nativt över all utrustning som läser in i BMS, utan konfiguration per tillgång. Vi har jämfört de ledande alternativen för programvara för tillståndsbaserat underhåll, inklusive var ett smalt CMMS-tillägg är tillräckligt och var du behöver en plattform byggd för det, separat, eftersom listan beror mycket på hur många byggnader och BMS-leverantörer du konsoliderar.

Vanliga frågor

Vad är tillståndsbaserat underhåll? En underhållspolicy som utlöser arbete baserat på tillståndsdata från utrustningen i realtid, en tröskelöverskridning i vibration, temperatur eller ström, snarare än ett fast kalenderintervall eller att vänta på fel.

Tillståndsbaserat underhåll jämfört med prediktivt underhåll, vad är skillnaden? Tillståndsbaserat underhåll agerar direkt på en tröskelöverskridning i tillståndsdata. Prediktivt underhåll lägger till en statistisk eller maskininlärningsmodell ovanpå samma data för att prognostisera ett felfönster i förväg. CBM är enklare att komma igång med och kräver inte felhistorik; prediktivt underhåll är mer precist men behöver mer data att träna mot.

Vilka sensorer behöver tillståndsbaserat underhåll? Det beror på felmoden du bevakar, vibrations- och temperatursensorer för roterande utrustning som pumpar och motorer, strömsensorer för elektriska laster, och oljeanalys för växellådor och stora kompressorer. De flesta fastighetsteam börjar med det deras BMS redan läser innan de lägger till dedikerade sensorer.

Är tillståndsbaserat underhåll samma sak som tillståndsövervakning? Nej. Tillståndsövervakning är sensor- och datalagret. Tillståndsbaserat underhåll är policyn som bestämmer vad som händer när den datan korsar ett tröskelvärde, tillståndsövervakning kan köra utan CBM kopplat till det, men CBM kan inte köra utan någon form av tillståndsövervakning som matar det.

Vilken programvara för tillståndsbaserat underhåll ska jag använda? Det beror på om du hanterar en enskild byggnad eller en portfölj över flera BMS-leverantörer. Se vår jämförelse av de ledande plattformarna för programvara för tillståndsbaserat underhåll för en genomgång.

Hur mycket kostar det att starta ett program för tillståndsbaserat underhåll? Kostnaden skalar med hur mycket du redan läser in i ditt BMS jämfört med hur många dedikerade sensorer du behöver lägga till. Team som börjar med de 10 till 20 objekten som redan orsakar mest oplanerat driftstopp, och lutar sig mot befintliga BMS-punkter innan de köper ny hårdvara, får ett fungerande program igång för en bråkdel av vad det skulle kosta att instrumentera en hel portfölj från början.