En linje stannar mitt i skiftet. Inom en sekund dyker tjugo rader upp på larmlistan: undertryck, motorns överström, en förregling, en ventilavvikelse, fem följdlarm. Operatören ser på listan och drar den enda möjliga slutsatsen: något gick sönder. Vilket som kom först — förreglingen eller pumpstoppet — går inte att avgöra, eftersom alla rader visar samma sekund.
Det här är larmhanteringens vardagsproblem, och det löses inte genom att lägga till fler larm. Det löses genom att bevara den information som redan fanns i automationssystemet: händelsernas inbördes ordning. OPC UA-larm bär den informationen med sig, förutsatt att de läses med standardens egen larmmodell i stället för att pollas som mätvärden.
Den här artikeln går igenom vad OPC UA:s modell Alarms & Conditions definierar, hur larm läses ur ett befintligt system utan ändringar, varför tidsstämpelns upplösning avgör grundorsaksanalysen — och vad som är värt att beräkna ur larmhistoriken när svallet är över.
Varför OPC UA-larm är en egen datatyp
Insamling av processdata och insamling av larm ser vid första anblicken ut som samma arbete: i båda fallen läses värden ur automationssystemet och lagras i en databas. I praktiken är det olika saker, och att blanda ihop dem är den vanligaste orsaken till att larmhistoriken inte ger någonting i efterhand.
Ett mätvärde är ett stickprov. Det beskriver en storhet vid ett givet ögonblick, och tillsammans bildar stickproven en kontinuerlig tidsserie. Om ett stickprov saknas är kurvan fortfarande begriplig — en trend tål en lucka.
Ett larm är en händelse. Det har ett exakt uppkomstögonblick, ett tillstånd, en allvarlighetsgrad, en källa och en livscykel: det utlöses, kvitteras eventuellt och återgår. En händelse är inte ett stickprov som kan tas om. Om den går förlorad, eller om dess tidsstämpel ersätts, är informationen borta för gott.
Skillnaden syns omedelbart i praktiken. I en typisk lösning läses ett larm som en variabel: varje sekund frågar systemet om en bit är satt. Då uppstår två problem oundvikligen:
- En händelse kortare än pollintervallet försvinner. Ett larm som utlöses och återgår inom samma sekund hinner aldrig synas i pollningen.
- Tidsstämpeln skapas på fel ställe. Ögonblicket som registreras är när pollningen råkade infalla — inte när händelsen uppstod. Pollintervallet och nätverkets fördröjning blandas in.
Just därför finns en separat larmmodell i OPC UA-standarden. OPC UA-larm är inte variabler som läses, utan händelser som servern publicerar.
Vad Alarms & Conditions (Part 9) definierar — och hur larmen läses
Alarms & Conditions är del 9 av OPC UA-standarden. Den definierar hur en server presenterar larm och händelser: vilka fält de innehåller, hur tillståndet ändras och hur en klient prenumererar på dem. Det är alltså ett gemensamt språk som alla OPC UA-kompatibla system talar — Siemens, ABB, Valmet, Beckhoff, Schneider Electric, Honeywell och Rockwell.
Kärnan i modellen är skillnaden mellan ett villkor och en händelse. Ett villkor (condition) är ett långvarigt tillstånd, till exempel "tanknivå över övre gränsen". En händelse (event) är ögonblicket då något ändrades: villkoret utlöstes, kvitterades eller återgick. Under sin livscykel producerar ett villkor flera händelser, och det är deras ordning som berättar vad som hände i processen.
Varje händelse bär med sig standardfält, varav fyra avgör utredningen:
Källa (SourceNode)
Vilken enhet eller processdel som gav upphov till händelsen. Detta binder larmet till ett fysiskt objekt i stället för till enbart en text — och gör filtrering per område möjlig.
Tidsstämpel (Time)
Ögonblicket då händelsen uppstod enligt servern. Det här är hela modellens värdefullaste fält, och det är också det fält som oftast går förlorat på vägen.
Allvarlighetsgrad (Severity)
En numerisk klassificering 1–1000. Med den skiljs bakgrundsbruset från kritiska händelser utan att varje rad läses för hand.
Meddelande och villkorets namn
En verbal beskrivning och villkorets identifierare. På dem vilar sökningen när enhetsbeteckningen inte är i minnet men larmets formulering känns igen.
Läsningen sker som en prenumeration, inte som pollning. Klienten talar om för servern en gång vilka händelser den är intresserad av, och servern skickar dem allteftersom de uppstår. Det är en viktig skillnad: en prenumeration har inget pollintervall som en händelse kan falla emellan.
Den praktiska följden är att idrifttagningen av larminsamlingen inte alls rör automationssystemet. Prenumerationen görs mot en befintlig OPC UA-server, som vanligtvis redan är i drift för ett SCADA-system eller en annan klient. DataPortia™ fungerar här till exempel som en ren OPC UA-klient: den prenumererar på händelser via gränssnittet Alarms & Conditions, skriver ingenting tillbaka, och varken logiken eller bildskärmsgrafiken behöver röras.
En förutsättning är värd att kontrollera i förväg
Servern måste publicera händelserna enligt modellen Alarms & Conditions. Alla system har inte en lika heltäckande larmmodell, och en begränsad modell syns direkt i vad som går att utreda ur historiken i efterhand. Det är värt att bekräfta innan mål sätts för larmanalysen.
Tidsstämpeln avgör grundorsaken: en millisekund i taget
När tjugo larm utlöses inom samma sekund kan grundorsaken skiljas från sina följder på exakt ett sätt: utifrån ordningen. Inte utifrån allvarlighetsgrad, inte utifrån meddelandets formulering, inte utifrån vad som råkar ligga överst i listan. Utifrån ordningen.
Därför är hanteringen av tidsstämpeln det enskilt viktigaste tekniska valet i larmhanteringen, och det är också den enda punkt där OPC UA-larm obemärkt kan förlora sin värdefullaste egenskap. Tre vanliga lösningar ger tre helt olika resultat:
| Lagrad tidsstämpel | Vad den kan fastställa | Vad som har gått förlorat |
|---|---|---|
| Serverns tidsstämpel, millisekundupplösning | Händelsernas inbördes ordning även inom samma sekund | Ingenting |
| Tidsstämpel avrundad till sekund | Endast vilka händelser som inföll under samma sekund | Ordningen inuti svallet — permanent |
| Skrivtid till databasen | I vilken ordning händelserna råkade komma fram | Den verkliga uppkomstordningen; nätets och köernas fördröjning blandas in |
Den mellersta raden är den man oftast stöter på. Avrundningen ser inte ut som ett fel i något skede: larmen är lagrade, listan ser prydlig ut och rapporten blir till. Först vid den första verkliga utredningen märker någon att frågan "vad utlöstes först" inte längre har något svar — och det går inte att få tillbaka med något verktyg, eftersom informationen förstördes i lagringsögonblicket.
Tidsordningsanalys av händelser (sequence of events, SOE) betyder helt enkelt att händelserna ordnas efter sin ursprungliga tidsstämpel och att man tittar på kedjans början. Det är en anspråkslös metod, och just därför fungerar den — så länge utgångsinformationen finns kvar.
- 1 ms
- är den upplösning där ordningen inuti ett svall fortfarande framträder. Avrundat till sekund har tjugo händelser fler möjliga ordningar än någon kan utesluta genom att titta — vilket i praktiken är ingen information alls.
Praktiskt exempel: ett stopp i ett fjärrvärmeverk och ett svall på tjugo rader
Fjärrvärmeverk: samma stopp med två olika tidsupplösningar
Praktiskt exempel
Tidsstämpel avrundad till sekund
- Pannans matarvattenpump stannade under nattskiftet
- 21 rader samlades på larmlistan, alla med samma sekund
- Ordningen i listan bestämdes av skrivordningen
- Två kandidater i utredningen: undertrycksförreglingen eller motorns överström
- Vilken som var orsaken förblev gissningar
- Åtgärden riktades mot båda — bortkastat arbete på den ena
Serverns ursprungliga millisekundstämpel
- Samma 21 händelser, samma sekund
- Den första händelsen framträdde: undertrycksförreglingen, 340 ms före de övriga
- Motorns överström följde 180 ms senare — alltså en följd
- De återstående 19 raderna var följder av kedjan, inte egna fel
- Utredningen inriktades på trycket på sugsidan, inte på motorn
- Samma vy exporterades till avvikelserapporten som den var
Värt att notera är att automationssystemet i båda fallen producerade exakt samma information. Skillnaden uppstod först i vad som lagrades av den. I det vänstra fallet finns alla 21 händelser fortfarande i databasen — bara deras inbördes ordning saknas, och den går inte längre att återställa.
I praktiken är arbetsgången för att reda ut ett svall oftast densamma: avgränsa tidsfönstret kring stoppet, avgränsa området till den processdel där kedjan började, och titta på kedjans första händelse. När larm och mätdata ligger i samma tidsseriedatabas kan samma fönster också ses som trendkurvor — och då syns vad trycket och flödet gjorde under de 340 millisekunderna.
Tre analyser som visar varifrån larmbelastningen kommer
Att utreda ett enskilt stopp är det användningsfall som OPC UA-larm oftast samlas in för. I vardagen är dock en annan fråga mer användbar: varför innehåller listan hundratals rader varje dag som ingen läser? Tre beräkningar svarar på det, alla gjorda ur samma händelsehistorik.
| Analys | Fråga den besvarar | Vad man gör med den |
|---|---|---|
| Pareto | Vilka larm återkommer oftast? | I toppen framträder de få punkter som fyller listan dag efter dag. Orsaken är oftast ett börvärde, en fördröjning eller en fladdrande kontakt. |
| Varaktighet | Vilka står på längst? | Ett larm som utlöses sällan men står på i en vecka framträder inte alls i antalen — det hittas bara genom att mäta varaktighet. |
| Allvarlighetsgrad | Hur mycket är verkligt kritiskt? | Fördelningen över allvarlighetsklasser visar hur mycket av listan som är bakgrundsbrus. Den är också den bästa grunden för att avgöra vad som ska filtreras bort. |
Resultatet av de tre är nästan alltid samma iakttagelse: en mycket liten grupp mätpunkter står för merparten av radantalet. När de tio översta punkterna har åtgärdats rasar larmlistans längd typiskt — och först då blir listan läsbar igen.
När larmhistoriken ligger i samma databas som mätdata kan analysen också utvidgas till fria frågor om materialet. DataPortias AI-modul kör en språkmodell på anläggningens egen server och läser samma data, så en larmperiod kan gås igenom utan att materialet flyttas någonstans.
Var larmanalysen inte räcker till
För rättvisans skull är det värt att också säga vad ett sådant upplägg inte gör.
- Upplösningen går inte att förbättra i efterhand. Om automationsservern stämplar händelserna på sekunden kan inget verktyg få fram ordningen. Lagringen kan bevara det servern ger, inte mer.
- Klockorna mellan servrar måste vara synkroniserade. Om larm läses från två system är ordningen mellan servrarna tillförlitlig endast om klockorna går lika. Det glöms ofta bort.
- Slutsatsen dras av en människa. Analysen ger ordning, antal och varaktigheter. Vad de betyder i processen vet de som känner anläggningen.
- Att förmedla aviseringar är något annat än historik. Larmen syns i webbgränssnittet och i rapporterna som sammanställs av det. SMS-aviseringar är inte tillgängliga, så att larma jouren sköts fortfarande med det system ni redan har för det.
De här gränserna är värda att känna till i förväg. De hindrar inte nyttan, men de avgör vad man ärligt kan lova sin egen organisation om larmhistoriken.
Sammanfattning: OPC UA-larm som verktyg, inte som brus
Det svåraste i larmhanteringen är inte att få OPC UA-larm insamlade. Det är att bevara den information som redan fanns i automationssystemet och som obemärkt försvinner på vägen till databasen.
De viktigaste lärdomarna:
- Ett larm är en händelse, inte ett stickprov. Läst genom pollning förlorar det både korta toppar och sitt verkliga uppkomstögonblick.
- Alarms & Conditions är standardens egen modell. Den fungerar med alla OPC UA-kompatibla system och kräver inga ändringar i automationen.
- Tidsstämpeln är hela kedjans kritiska punkt. En stämpel avrundad till sekund förstör ordningen permanent.
- Pareto, varaktighet och allvarlighetsgrad visar varifrån belastningen kommer. Ett fåtal punkter står oftast för merparten av raderna.
- Gränserna är värda att säga högt. Lagringen förbättrar inte källsystemets upplösning, och slutsatsen dras fortfarande av en människa.
När larm, mätdata och rapportering hör till samma helhet på anläggningens egen server blir utredningen färdig i samma vy där den gjordes — utan att materialet flyttas någonstans. Testa DataPortia gratis i 30 dagar: testperioden omfattar alla funktioner utom HA-tillägget och binder inte till något, och larmen läses direkt från ert eget automationssystems gränssnitt Alarms & Conditions. Först då ser ni om den verkliga första händelsen framträder ur ert eget svall.