Systemkrav Infrasystem Väg: Larm- och händelsehantering

Transkript

1 1 (10) Skapat av (Efternamn, Förnamn, org) DokumentID Ev. ärendenummer Lars Jonsson UHniö [DokumentID] [Ärendenummer] Fastställt av Dokumentdatum Version Leif Lindmark Dokumenttitel Systemkrav Infrasystem Väg: Larm- och händelsehantering 1 1 Inledning Tillämplighet Medgällande dokument Trafikverkets styrande dokument Omfattning Definitioner Definitioner avseende larmhantering Händelser Larm Larminstans Larmmeddelande Larmtyp Larmkod Händelsenamn Larmnamn Larmkategori Larmprioritet Larmundertryckning och blockering Larmgenerering Filtrering Larmstatus Kvittering Krav Omfattning Anslutning mot överordnade system Larmupplösning Information för larm och händelser Omdefiniering av larm Larmgenerering Larmundertryckning och blockering Tidsmärkning Larminstruktion Loggning av larm och händelser Lagring av larm och händelser... 10

2 2 (10) 6.12 Anläggningar med högre krav på lagring av larm och händelser... 10

3 3 (10) 1 Inledning Detta dokument definierar Trafikverket Infrasystems systemkrav avseende larm och händelsehantering i väganläggningar anslutna till överordnade system. Systemkrav är riktade mot entreprenör, och avsedda att åberopa i förfrågningsunderlag avseende entreprenad. Förbättringsförslag som berör detta dokument ska ställas till enheten för elkraftsystem via elkraft@trafikverket.se. Fotnoter är råd/instruktioner till den som använder dokumentet för kravställande. 2 Tillämplighet Detta dokument är tillämpligt för installationer vid väg. 3 Medgällande dokument Följande dokument i angiven version åberopas/hänvisas till i detta dokument: 3.1 Trafikverkets styrande dokument Beteckning Version Namn 2007: Principer för systemnummer och komponentbeteckningar 1.0 Systemkrav Infrasystem Väg: Statistikdatagränssnitt för anläggningar 4 Omfattning Dokumentet definierar begrepp för användning i Trafikverkets styr och övervakningssystem {5.1 Definitioner avseende larmhantering och ställer krav på larmhantering {6 Krav}. Dokumentet omfattar larm och händelser. Dokumentet omfattar inte hantering av mätvärden. 5 Definitioner ASÖ Felfunktionsläge Komplex anläggning NTS RFI Anläggningsövergripande styr- och övervakningssystem Läge som en styrenhet intar för styrning av enheter med felfunktion i syfte att minimera konsekvenserna av felet. Större anläggningar där flera olika typer av system integreras som t.ex. tunnlar och öppningsbara broar med lokala styr och övervakningssystem. Nationellt Trafikledningsstöd system/operatörsstöd för vägtrafikledning och väganläggningsövervakning. Request For Information är ett dokument som lämnas in vid anslutning av ett system till NTS och innehåller information om varje objekt och varje NTS-larmkod för att NTS ska kunna hantera anläggningen.

4 4 (10) Spårning Säkert läge Loggning av vilken användare eller system som genomför en åtgärd. Ett läge som intas av styrenhet för att hålla en anläggning så säker som möjligt för tredje man när kommunikationen är avbruten. 5.1 Definitioner avseende larmhantering 5.2 Händelser Händelser är alla typer av förändringar som går att förena med normala drifttillstånd och som behöver uppmärksammas, vilket omfattar alla statusförändringar. Exempel på statusförändringar är: Tillslag av pump Frånslag av pump Manöver av pump Statusändring för vattenpump (t.ex. lokal styrning) Blockering av larm 5.3 Larm Larm är alla typer av förändringar som uppstår från onormala driftstillstånd i en anläggning och som föranleder en åtgärd. Exempel på larm är: Utlöst huvudsäkring Temperatur i brandkabel överstiger gränsvärde för brandlarm Stillastående fordon i tunnel Trasig fläkt Öppen dörr i apparatskåp Överskriden drifttid 5.4 Larminstans Ett enskilt larm för ett objekt och den status som är kopplad till larmet benämns som larminstans. När larmvillkoren för samma larminstans uppfylls flera gånger det vill säga statusen ändras från aktiv, till inaktiv och sedan till aktiv igen är det en och samma larminstans som ändrar status mellan aktiv och inaktiv. 5.5 Larmmeddelande Information som skickas till andra system om en larminstans statusändring mellan inaktiv och aktiv benämns som larmmeddelande. Varje gång en larminstans ändrar status mellan inaktiv och aktiv kan det skickas ett nytt larmmedelande till andra system. Exempel: När en dörr till en viss teknikkiosk öppnas uppstår ett larm för larminstansen med orsaken öppen dörr. När dörren öppnas flera gånger efter varandra ändras statusen på en och samma larminstans, men till andra system kan det skickas flera larmmeddelanden.

5 5 (10) 5.6 Larmtyp Larmtypen är kopplad till objekttyp och identifieras av larmtypens larmkod, alla larminstanser med samma larmkod tillhör samma larmtyp. 5.7 Larmkod Larmkoden identifierar vilken larmtyp som ett larm tillhör. Larmkoden är unik för en anläggning och kopplad till objekttyp. Exempel: Till objekttypen passagekontroll hör larmtypen Dörr öppen med sin unika larmkod. Alla Dörr öppen larminstanser hörande till alla passagekontrollobjekt tillhör därför samma larmtyp och har samma larmkod. en för Dörr öppen kan däremot inte förekomma för en annan objekttyp i en och samma anläggning. 5.8 Händelsenamn Händelsenamnet består av komponent-id för objektet och ett suffix. Händelsenamnet betecknar en händelse. Suffixen i händelsenamnen är desamma för alla händelser av samma typ. Exempel: Två händelsenamn för två olika dränkbara pumpar för samma typ av händelse Från har olika händelsenamn men samma suffix =511PU201H =512PU902H Larmnamn Larmnamnet består av komponent-id för objektet och ett suffix (larmkod). Larmnamnet betecknar en larminstans. Suffixen (larmkoderna) i larmnamnen är desamma för alla larm av samma larmtyp. Exempel: Två larmnamn för två olika kameror av samma larmtyp Videosignal saknas har olika larmnamn men samma suffix (larmkod). AB+21102=841BV254A001 AB+21102=841BV253A Larmkategori Genom användning av kategorier går det att dela upp larm av olika slag för indikering eller olika hantering t.ex. trafikala larm och tekniska larm Larmprioritet Larmprioritet används för att avgöra vilket larm som ska prioriteras och också avgöra hur snabbt larmet måste hanteras Larmundertryckning och blockering Larmundertryckning och blockering är funktioner som används för att se till att bara de larm som föranleder en åtgärd är tillgängliga i operatörsgränssnittet. I figuren nedan kan vi se hur larmundertryckning och blockering hanteras på väg mot operatören.

6 6 (10) Figur 1 Larmförädlingskedjan från larmgenerering till loggning. Undertryckta och blockerade larm loggas inte, men blockerade larm återfinns i en lista över blockerade larm LARMUNDERTRYCKNING Larmundertryckning görs av logik i styrenhet för att t.ex. endast skicka det första initierade larmet och inte dess följdlarm. Till exempel om matande system för elkraft faller bort ska följdlarm i inkopplade system som är orsakade av felet i det matande systemet undertryckas. Exempel: Utlöst huvudsäkring vilken matar undersystem BLOCKERING AV LARM Blockering av larm görs manuellt genom att antingen blockera ett specifikt larm eller genom att blockera alla larm kopplade till ett objekt. Blockering per objekt är användbart till exempel vid servicearbeten Larmgenerering Larmgenerering är den funktion som skapar ett larm när larmvillkoren är uppfyllda. Innan larmet genereras kan larmvillkoren påverkas av parametrar för larmgenerering som hysteres och fördröjning. Parametrarna kan användas för att undvika att generera många larmmeddelanden t.ex. vid tillfällen när fluktuerande mätvärden eller kortvariga störningar annars skulle ge uppfyllda larmvillkor Filtrering Filtrering är något som en operatör gör i operatörsgränssnittet för att slippa se larm och händelser, t.ex. i en larmlista eller på en karta, som inte är relevanta för den operatören. Filtrering kan göras på t.ex. prioritet, kategori, datum, tid, till, frånslag eller beteckning Larmstatus Ett larm kan ha olika larmstatus. Med det menas att larminstansen har intagit larmstatus enligt nedan. Statusflagga Statusvärden Beskrivning AktivStatus Aktivt, Inaktivt Anger huruvida larmkriterier är

7 7 (10) uppfyllda eller ej KvitteringStatus Kvitterat, Okvitterat Anger huruvida Larminstans är kvitterat eller okvitterat. BlockeringStatus Blockerat, Oblockerat Anger huruvida Larminstans är blockerad eller oblockerad. Möjliga statuskombinationer för ett larm finns beskrivna i tabellen nedan: AktivStatus KvitteringStatus BlockeringStatus Aktiv Okvitterat Oblockerat Aktiv Kvitterat Oblockerat Inaktiv Okvitterat Oblockerat Inaktiv Kvitterat Oblockerat N.A N.A Blockerat 5.16 Kvittering Kvittering av ett larm innebär att någon har tagit hand om och hanterar larmet. Kvitteringen innebär att larminstansens status ändras till kvitterat. Oavsett hur många gånger som larminstansens status har ändrats mellan inaktiv och aktiv räcker det med en kvittering för att larminstansens status ska ändras till kvitterat. Exempel: När ett larm aktiveras indikeras det i operatörsgränssnittet för styrsystemet att det finns ett larm som behöver hanteras. När en operatör börjar hantera larmet ska larmet ändra status till kvitterat och indikationen på larmet i operatörsgränssnittet ändras så att alla kan se att larmet nu hanteras av en operatör. Oavsett om kvittering av ett larm sker på grund av en operatörsaktivitet eller av ett anslutet system är hanteringen i styrsytemet lika. Inom anläggningen sker synkronisering av larmstatus, det vill t.ex. säga att kvittering i OP-paneler och SCADA skickas mellan varandra. Larmstatus synkroniseras normalt mellan anläggning och överordnat system som t.ex. NTS. Kvittering i ett överordnat system som t.ex. NTS innebär att det skickas en kvittering till anläggningen och en kvittering i anläggningen att det skickas en kvittering till överordnat system. Att ett larm blir inaktivt i anläggningen rapporteras upp till överordnat system. 6 Krav 6.1 Omfattning K.1. Förslag till larm och händelser ska utarbetas av entreprenören och godtagas av beställaren.

8 8 (10) 6.2 Anslutning mot överordnade system K.2. Anläggningen ska överföra alla larm, larmstatus och övrig larminformation till överordnade system. K.3. Vid aktivering, kvittering och inaktivering av larm ska styrsystemet alltid uppdatera överordnade system. 6.3 Larmupplösning K.4. Generellt gäller att alla larm från ett undersystem ska indikeras i anläggningen. K.5. Summalarm får ej användas om sådana omöjliggör korrekt larmundertryckning eller relevant felsökning. Exempelvis ska säkringar i fördelningar och dylikt vara försedda med enskilda larmkontakter. 6.4 Information för larm och händelser K.6. Larm ska vara relevanta och entydiga, samt underlätta felsökning och avhjälpande åtgärder. K.7. Alla signaler för händelser och larm ska förses med följande attribut: Attribut Beskrivning Format Larmnamn/ Händelsenamn Larmtext Kategori Ett unikt namn på en larminstans eller händelse. Larmtexten är en beskrivande klartextbeskrivning av larmet. Genom användning av kategorier ska det gå att skilja mellan olika typer av larm och händelser. Trafikala larm (Kategori T) och larm tillhörande drift/tekniska fel (Kategori D), händelser med användarinteraktion (Kategori User) eller en systeminitierad händelse Enligt {Riktlinjer Statistikdatagränssnitt för anläggningar}. Klartextbeskrivningen ska innehålla teckenseparerad information om objekttyp, och larmorsak för larmet. I vissa fall t.ex. för ställverk kan plats också behövas. Exempel på hur en larmtext kan byggas upp är: (Tilluftsfläkt: Temperaturvakt). Exempel med plats inkluderad (0,4kV Ställverk: FACK S4 Summalarm utlöst brytare). Textsträng: larm {T, D} (T och D kan i larmlista ersättas med 1 respektive 2) och händelser {USER, EVEN}.

9 9 (10) (Kategori Even(t)). Prioritet Larm ska indelas i tre olika prioritetsnivåer: Prioritet 1 larm som kräver omedelbar åtgärd. Prioritet 2 larm som inte kräver omedelbar åtgärd, men som ska planeras under nästföljande arbetspass. Prioritet 3 larm som ska åtgärdas vid nästa planerade underhållsinsats. En numerisk siffra {1, 2, 3, }. K.8. Funktionalitet för att filtrera larm och händelser ska finnas i anläggningens operatörsgränssnitt. 6.5 Omdefiniering av larm K.9. Hur larm och händelser hanteras kan komma att ändras över tid. Anläggningen ska byggas upp för att på ett flexibelt sätt kunna hantera detta. Exempelvis ska ändring av prioritet samt kategori kunna göras för larm och händelser. 6.6 Larmgenerering K.10. Gränsvärdeslarm ska vara inställbara från operatörsgränssnittet och ha justerbar hysteres. K.11. Varje enskilt larm ska kunna fördröjas via inställbar parameter. Genom fördröjning av larm ska det vara möjligt att undvika oönskade larm orsakade t.ex. av kortvariga störningar. 6.7 Larmundertryckning och blockering K.12. Följdlarmer ska automatiskt undertryckas på ett sådant sätt att orsaken (felkällan) till larmen tydligt framgår i operatörsgränssnittet. Syftet är att undvika att det larm som ska hanteras blandas ihop med ett flertal följdlarm. Via händelser och statusförändringar ska dock skeendet i sin helhet vara möjligt att följa. K.13. Vid larmundertryckning och blockering ska larm inte loggas. K.14. Larmupplösningen ska vara tillräcklig för att en korrekt larmundertryckning ska ske. K.15. Följdlarm ska undertryckas på en så låg systemnivå som möjligt. Med detta menas, i styrenhet så nära larmande objekt som möjligt. K.16. Summalarm får ej användas om sådana omöjliggör korrekt larmundertryckning. Undantag specificeras separat. K.17. Funktionalitet för larmblockering ska finnas för alla larm.

10 10 (10) 6.8 Tidsmärkning KRAV PÅ TIDSMÄRKNING K.18. Tidsupplösning och noggrannhet för tidsmärkning av en händelse/larm ska vara max 2 sekunder. Larm som i verkligheten inträffar med en tidsdifferens om 2 sekunder eller mer ska vara tidsmärkta så att den ordning i vilken händelse/larm inträffade kan utläsas ANLÄGGNINGAR MED HÖGRE KRAV PÅ TIDSMÄRKNING K.19. Tidsupplösning och noggrannhet för tidsmärkning av en händelse/larmdetektering ska vara max 200 ms för ej tidskritiska förlopp. Larm som i verkligheten inträffar med en tidsdifferens om 200 ms eller mer ska vara tidsmärkta i korrekt ordning. K.20. Tidsupplösning och noggrannhet för tidsmärkning av en händelse/larmdetektering ska vara max 10 ms för tidskritiska förlopp, exempelvis vid utlösning av brytare i ställverk. Larm som i verkligheten inträffar med en tidsdifferens om 10 ms eller mer ska vara tidsmärkta så att den ordning i vilken händelse/larm inträffade kan utläsas. 6.9 Larminstruktion K.21. Varje enskilt felfall ska utredas och en larminstruktion tas fram viket beskriver troliga felorsaker och hur de åtgärdas 6.10 Loggning av larm och händelser K.22. Information såsom händelser och larm ska loggas i anläggningen. K.23. Spårning ska ske vid all in/utloggning, blockering, avblockering, manövrering, operatörsförändring av inställningsbara värden, kvittering och andra manuella händelser och larm. K.24. Data från anläggningen ska följa krav i enlighet med {Riktlinje Statistikdatagränssnitt för anläggningar} i sin helhet Lagring av larm och händelser K.25. Loggar och liknande för larm och händelser i anläggningar ska kunna lagra minsta 1000 larm och händelser och överbrygga kommunikationsbortfall till centrala system på minst 10 dagar utan att förlora larm och händelser Anläggningar med högre krav på lagring av larm och händelser K.26. Loggar och liknande för larm och händelser i anläggningar med högre krav ska lagras i minst 1,5 år. Detta då historisk data används för presentation. Fastställd version Dokumentdatum Ändring Namn Första fastställda Joakim Frank UHaen version