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

Tillståndsbaserat underhåll förklarat: hur det skiljer sig från prediktivt och förebyggande underhåll, när man ska använda det och hur man bygger en policy som håller.

Publicerad12 augusti 2026Lästid11 min läsning
En tekniker inspekterar industriell utrustning med en checklista i handen, och samlar in tillståndsdata för ett underhållsbeslut.

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.

StrategiUtlösareData som krävsLedtid före felBäst lämpad för
Reaktivt (drift till fel)Utrustning går sönderIngenIngenLågvärdesutrustning, redundant utrustning
FörebyggandeFast kalender eller drifttidsintervallTillverkarens schemaEj tillämpligt (godtyckligt)Utrustning med välkända slitagekurvor
Tillståndsbaserat underhållSensoravläsning korsar ett tröskelvärdeLevande tillståndsdata (vibration, temperatur, ström, etc.)Dagar till veckorKritisk utrustning med oregelbundet slitage
Prediktivt underhållModell prognostiserar kvarvarande användbar livslängdTillståndsdata plus historisk feldata och en modellVeckor till månaderHögvärdesobjekt där driftstoppskostnaden motiverar modellering

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.

P-F-kurvan: varför tröskeltajmning spelar roll

Baslinjen och tröskelvärdet från steget ovan är inte godtyckliga. De är en gissning om var du befinner dig på P-F-kurvan, modellen bakom varje tillståndsövervakningsteknik.

Varje felmod rör sig genom en degraderingskurva med två namngivna punkter. P är den potentiella felpunkten, den tidigaste tidpunkten en teknik kan upptäcka att något har börjat gå fel. F är funktionellt fel, ögonblicket tillgången slutar fungera. Gapet mellan dem, P-F-intervallet, är hela varningsfönstret. Allt användbart händer inom det.

Sätt tröskeln för nära F och det finns ingen tid kvar att schemalägga en tekniker eller beställa en del. Sätt den för nära P och programmet genererar arbetsordrar på utrustning som fortfarande har veckor av säker drift kvar. Intervallet varierar beroende på felmod och teknik: ett spjälkande lager syns i en ultraljudsavläsning innan det syns i vibrationsdata, och i vibrationsdata innan en värmekamera fångar det när det går varmt. Det är det praktiska skälet till att kritisk utrustning ofta bär mer än en teknik. Var och en köper en annan del av P-F-intervallet.

Tillståndsbaserade underhållstekniker

Att instrumentera en tillgång handlar om att välja från en specifik verktygslåda, och rätt verktyg beror på felmoden du bevakar. Fem tekniker täcker det mesta av vad ett fastighetsprogram för CBM faktiskt använder.

Vibrationsanalys. Accelerometrar på pumpar, motorer, fläktar och kompressorer fångar lagerslitage, feljustering och obalans genom förändringar i vibrationsamplitud och frekvens. Mindre kritisk utrustning får en handhållen mätare på en månatlig eller kvartalsvis rutt; kritiska kylmaskiner och pumpar bär allt oftare permanent monterade sensorer som strömmar in i BMS:et.

Infraröd och termisk avbildning. En värmekamera läser yttemperatur utan kontakt, fångar lösa anslutningar och obalanserade laster i ställverk innan de bågar, och överhettade lager på mekanisk utrustning. Nästan alltid ruttbaserad, en kvartals- eller årsscanning med en handhållen kamera, även om fasta termiska sensorer börjar dyka upp på den mest riskfyllda elutrustningen.

Olje- och smörjmedelsanalys. Laboratorieanalys av olja från växellådor, stora kompressorer och oljesmorda kylmaskinslager mäter slitagepartiklar av metall, vattenkontamination och additivnedbrytning, ser inre slitage direkt snarare än som ett yttre symptom. Prover tas vanligtvis på en rutt och skickas till ett labb; de mest värdefulla kylmaskinerna börjar bära online-partikelräknare som hoppar över labbfördröjningen.

Ultraljudstestning. Luftburna ultraljudsdetektorer fångar upp tryckluft- och köldmedieläckor och elektrisk ljusbågning i ställverk, allt ohörbart för människoörat. Strukturburna (kontakt-) sonder lyssnar direkt på ett lager och fångar smörjningskollaps tidigare än vad vibrationsanalys vanligtvis gör. Båda är mestadels handhållna ruttinstrument, även om kontaktsensorer allt oftare monteras permanent på kritiska lager.

Motorströmsignaturanalys (MCSA). Strömtransformatorer, tång eller permanent inkopplade, analyserar en motors elektriska vågform för brutna rotorstavar, luftgapsexcentricitet och lagerfel, diagnostiserar mekaniska problem utan att öppna motorn eller komma åt en riskfylld plats. En tångmätare täcker en rutt över mindre motorer; kritiska fläktar och pumpar får allt oftare transformatorer fast inkopplade i motorstyrcentralen, som matar data direkt in i BMS:et.

Typer av tillståndsbaserat underhåll: online kontra periodiskt

Dessa tekniker delas upp i två utplaceringsmodeller, och de flesta program kör båda.

Online (kontinuerligt) CBM använder permanent monterade sensorer som strömmar data konstant. Det passar utrustning där fel är dyrt och P-F-intervallet är kort: kylmaskiner, kritiska pumpar, kyltornsväxellådor.

Periodiskt (ruttbaserat) CBM skickar en tekniker runt med portabla instrument enligt ett fast schema, månatligt eller kvartalsvis. Det kostar mindre att sätta upp över en stor utrustningspopulation och passar tillgångar med längre P-F-intervall eller lägre felkonsekvens: sekundära pumpar, mindre motorer, allmän mekanisk rumsutrustning.

Uppdelningen är inte permanent. Utrustning som börjar på en rutt går ofta vidare till onlineövervakning när den upprepade gånger dyker upp i loggen för oplanerade driftstopp, samma kriterium som avgör vilka tillgångar som instrumenteras överhuvudtaget.

Standarderna bakom ett försvarbart CBM-program

Två ISO-standarder styr hur tillståndsbaserat underhåll är tänkt att fungera, och de flesta fastighetsteam har aldrig hört talas om någon av dem.

ISO 17359 (tillståndsövervakning och diagnostik av maskiner, allmänna riktlinjer) är processstandarden. Den täcker hur man väljer vilka tillgångar som ska övervakas, väljer mättekniker, och strukturerar beslutslogiken som förvandlar en avläsning till en åtgärd: ramverksversionen av slingan som beskrivs ovan.

ISO 13374 (tillståndsövervakning och diagnostik av maskinsystem, databehandling, kommunikation och presentation) är dataarkitekturstandarden. Den definierar hur tillståndsdata ska röra sig genom ett system, från insamling genom tillståndsdetektering och hälsobedömning till prognostik och rådgivning, som en definierad pipeline snarare än ett proprietärt format hopsatt av vilken leverantör som helst som sålde sensorerna.

Ingen av dem är ett juridiskt krav. De spelar roll av två skäl. Försvarbarhet: när en revisor eller investeringskommitté frågar varför en tröskel ligger där den ligger, slår hänvisning till en erkänd process en ingenjörs magkänsla. Interoperabilitet: data strukturerad enligt ISO 13374:s pipeline passar in i andra verktyg som förväntar sig samma struktur, vilket spelar roll i samma stund en portfölj kör mer än en BMS-leverantör eller övervakningsplattform.

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.

Prediktivt underhåll jämfört med förebyggande underhåll, vad är skillnaden? Förebyggande underhåll körs på ett kalender- eller drifttidsintervall oavsett om objektet behöver arbetet. Prediktivt underhåll använder modeller på tillståndsdata för att prognostisera ett felfönster så att jobbet landar före felet, inte på ett fast schema. I byggnader passar förebyggande underhåll objekt med stabilt slitage och tydliga OEM-intervall; prediktivt passar högriskobjekt där du har tillräcklig historik att träna mot. Tillståndsbaserat underhåll ligger mellan dem: det utlöses på en tröskelöverskridning utan att kräva en prognosmodell. För byggnadsvinkeln, se prediktivt underhåll i byggnader och vår jämförelse av programvara för prediktivt underhåll.

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.

FrostLogic Explore levererar sensor intelligence, scenariosimulering och förankrad slutlednings-AI till kommersiella och industriella byggnader. Lär dig mer om Sensor Intelligence eller prata igenom det med oss.

Nyfiken på hur detta skulle se ut på din byggnad?

Vad berättar din fastighet inte för dig?

Berätta vad du försöker reda ut: energiförbrukning som smyger uppåt, ett BMS du inte litar på, compliance du jagar. Vi lyssnar först och säger sedan rakt ut om Explore hjälper. 30 eller 60 minuter, du väljer. Inga förpliktelser, oavsett vad.