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

1 (8) Skapat av (Efternamn, Förnamn, org) DokumentID Ev. ärendenummer Lars Jonsson UHniö [DokumentID] [Ärendenummer] Fastställt av Dokumentdatum Version Leif Lindmark 2013-03-26 2.0 Dokumenttitel Systemkrav Infrasystem Väg: Larm- och händelsehantering 1 1 Inledning... 2 2 Tillämplighet... 2 3 Statistik i anläggningar... 2 3.1 Användning av statistik... 2 3.2 Realtids och icke realtids-gränssnitt... 2 4 Definitioner... 3 5 Krav på statistikdatagränssnitt... 4 5.1 Åtkomst till data... 4 5.2 Integritet och validering... 4 5.3 Lagring av data... 4 5.4 Information i databasen... 5

2 (8) 1 Inledning Detta dokument definierar Trafikverket Infrasystems systemkrav avseende statistikdatagränssnitt mot väganläggningar. 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 vid anslutning av anläggning till statistikdatabas. 3 Statistik i anläggningar 3.1 Användning av statistik Trafikverket använder statistik från anläggningar i sitt förvaltningsarbete. Statistiken används bland annat för att: Förbättra larmsituationen för operatörer Upprätthålla tillgänglighet och funktion Utvärdera utrustningar och tekniska lösningar Följa trender i mätvärden Planera förebyggande underhåll Utvärdera funktion. 3.2 Realtids och icke realtids-gränssnitt Det finns två huvudtyper av gränssnitt för anslutning av anläggningar mot centrala system i Trafikverket väg, realtidsgränssnitt för styrning och övervakning och icke realtidsgränssnitt för överföring av statistikinformation. Realtidsgränssnitten är mellan NTS, regionala system och lokala system, men statistikgränssnitten är mellan nationell statistikdatabas och regionala och lokala system. Realtidssgränssnittet kan gå direkt från ett lokalt system t.ex. i en komplex anläggning eller via ett regionalt system t.ex. för mindre anläggningar.

3 (8) Figur 1 Realtids- och icke realtidsgränssnitt Överföring mellan system och statistik databas sker alltid via ett mellanlager för att skydda produktionsmiljön. Överföring till mellanlager sker internt i applikationen. Beroende på förutsättningar så kan statistikinformation överföras till statistikdatabas från lokalt mellanlager eller överföras via realtidsgränssnitt mellan lokalt och regionalt system och mellanlagras på regional nivå för att tillåta enklare utrustning på lokal nivå. Överföring till statistikdatabasen ska dock alltid ske via ett icke realtidsgränssnitt enligt detta dokument. 4 Definitioner Dynamisk data Händelse Larm Larmstatusförändring Lokalt system Mellanlager Metadata Dynamisk data är data som förändras under drift, till exempel mätvärden, data om vilket larm eller vilken händelse som inträffar. Händelser är förändringar i status som går att förena med normala driftstillstånd. Larm är förändringar som är kopplade till onormala driftstillstånd och föranleder normalt någon sorts åtgärd. Larmstatusförändring är alla nya larm och alla statusförändringar och kvittenser av redan existerande larm. Lokalt system är det övervaknings och styrsystem som är placerat närmast anläggningen och betraktas som en del av anläggningen. Lokalt system kan kopplas direkt mot Nationellt system för större anläggningar (t.ex. av typen tunnlar, broar etc). Mellanlagring av data för att separera produktionsdata från statistikdata. Metadata är statisk data som inte förändras under normal drift och som beskriver dynamiskt data. Ändras inte för varje händelse, larm och trenddata.

4 (8) MMI NTS Regionalt System Tabell Man Machine Interface benämning på ett användargränssnitt Nationellt Tekniskt System Regionalt system är ett system som samlar ihop ett antal mindre lokala anläggningar av samma typ, ofta utrustningar som är utspridda över större områden längs med vägar. Sammanhållen informationsmängd som ska vara föremål för överföring till statistikdatabas. 5 Krav 5.1 Åtkomst till data K.1. Statistikgränssnittet ska skapas genom att ge Trafikverket åtkomst till information enligt detta dokument. K.2. Åtkomsten ska vara skyddad med användarnamn och lösenord och ska möjliggöra för Trafikverket att hämta, skriva och radera information. K.3. Informationen ska lagras på ett sådant sätt att trafikverket inte löper risk att påverka data i produktion eller på annat sätt störa system i produktion vid läsning och radering av data. För att uppnå det ska data som Trafikverket har tillgång till lagras i ett mellanlager separerat från produktionsdata. 5.2 Integritet och validering K.4. Informationen som trafikverket har tillgång till för statistiköverföring får inte raderas annat än med tillstånd av Trafikverket eller för att hindra lagringsmedia från att bli fullt enligt nedan och ska inte raderas utav aktiviteter i styr och övervakningssystemet. K.5. För att begränsa storleken på den lagrade informationen och hindra att lagringsmedia blir fullt får data som är äldre än 60 dagar och hämtat av Trafikverket raderas. För att vara robust mot fel i överföring ska information lagras minst i 60 dagar. K.6. Alla larm och händelser i styr och övervakningssystemet ska skrivas ned i tabeller med en ny rad för varje händelse eller larmstatusförändring enligt5.4.5. K.7. Till varje tabell med data ska en tabellpost i en loggtabell finnas där Trafikverket kan skriva ned datum och tid för senaste överföring av data och senaste överlästa ID. K.8. Larm på missad överföring ska genereras i övervaknings och styrsystemet när tid för senaste överföring är äldre än en definierad tid. Den definierade tiden ska vara ställbar och med ett defaultvärde på 96 timmar. Överföringstiden ska kontrolleras minst en gång per 24 timmar. Tid för senaste kontroll av överföringstiden skall skrivas ned i loggtabell. 5.3 Lagring av data K.9. Dynamisk data och metadata ska lagras i separata tabeller med pekare mellan tabellerna för att optimera lagringsstorlek på mellanlager.

5 (8) 5.4 Information i databasen K.10. Tabellerna ska innehålla tillräcklig information för att följa alla larms larmstatus och se och förstå vilka händelser som inträffar med möjlighet att: analysera larm, utvärdera funktion, räkna ut drifttider på utrustningar etc. K.11. Informationen i databasen ska innehålla information om larmdata, händelsedata och trenddata. 5.4.1 LARM OCH HÄNDELSEDATA K.12. Larmdata och händelsedata ska innehålla information om alla händelser, larm och statusändringar och ska minst innehålla information enligt tabell 1 nedan. Tabell 1 Data och information för larm eller händelse Datatyp Information Beskrivning Dynamisk data ID Data ska i databastabellerna ha en unik identifierare som inte får återanvändas och som räknas upp med 1 för varje ny rad i tabellen. Syftet med räknaren är att underlätta validering av databaserna. Dynamisk data Tidsstämpel Tidsstämpel för varje händelse eller larm. Tidsstämpel ska lagras med den upplösning som är kravställd dock minst med sekundupplösning enligt format i 5.4.4 nedan. Dynamisk data Larm/händelsestatus Beskriver vilken statusändring som larm/händelsen avser, se 5.4.5 nedan Dynamisk data Aktör För händelser som t.ex. manövrering, blockering, deblockering. Den aktör som har initierat aktiviteten kan vara en inloggad användare eller ett anslutet system. Metadata Larm/händelsekategori och prioritet Larmens kategori och prioritet enligt format nedan 5.4.6 Metadata Larmnamn Ett unikt namn på larmet/händelsen enligt format i kapitel 5.4.7 nedan (alarmname). Metadata Textbeskrivning Text som beskriver larm/händelse samma text som i styr och övervakningssystem. 5.4.2 TRENDDATA K.13. Trenddata ska innehålla alla mätvärden och information om mätvärden minst enligt tabell 2 nedan. Tabell 2 Data och information för Trenddata Datatyp Information Beskrivning

6 (8) Dynamisk data ID Data ska i databastabellerna ha en unik identifierare som inte får återanvändas och som räknas upp med 1 för varje ny rad i tabellen. Syftet med räknaren är att underlätta validering av databaserna. Dynamisk data Tidsstämpel Tidsstämpel för varje mätning. Tidsstämpel ska lagras med den upplösning som är kravställd dock minst med sekundupplösning enligt format i 5.4.4 nedan. Metadata Mätområde Mätområdet angett som minvärde och maxvärde för mätvärdet. Dynamisk data Mätvärde Värdet för varje mätning. Metadata Enhet Enheten på den utförda mätningen Metadata Mätningsnamn Ett unikt namn eller tag på mätningen enligt format i kapitel 5.4.8 nedan (trendname). Metadata Mätningstext Beskrivning av vad mätningen avser. Metadata Samplingsintervall Samplingsintervall för mätningen i anläggningen angett i sekunder. 5.4.3 LOGGTABELL K.14. Loggtabell ska innehålla alla mätvärden och information minst enligt tabell 3 nedan. Tabell 3 Loggtabell Information Tabellnamn Tidsstämpel läsning Tidsstämpel kontroll Senast överförda ID Beskrivning Namn på tabell som avses. Tidsstämpel för senaste överföring till statistikdatabas. Tidsstämpel för senaste kontroll av överföring. ID för den senast överförda posten till statistikdatabas. 5.4.4 FORMAT FÖR TIDSSTÄMPEL K.15. Tidsstämpel ska anges i tidsformat enligt nedan: YYYY-MM-DD HH:MM:SS och när krav på millisekunder finns.fff K.16. Tidsangivelse ska anges som GMT+1. 5.4.5 FORMAT FÖR LARM/HÄNDELSESTATUS K.17. Larm och händelsestatus ska vara en av 5 olika statusändringar:

7 (8) 1 = Active - Skickas när larm blir aktivt eller vid tillslag av utrustning 2 = Inactive - Skickas när larm blir inaktivt eller vid frånslag av utrustning 3 =Disabled - Skickas vid blockering av larm eller vid avställning av objekt 4 =Enabled - Skickas vid deblockering av larm eller vid påställning av ett objekt 5 =Acknowledged - Skickas vid kvittering av larm 5.4.6 FORMAT FÖR LARMKATEGORI OCH PRIORITET K.18. Prioritet och kategori för larm ska lagras i databastabell enligt formatbeskrivningen nedan: Prioritet: 1 = Omedelbar åtgärd 2 = Åtgärd planeras in under nästa arbetspass 3 = Åtgärd planeras in under nästa underhållsåtgärd Kategori: T = Trafikala larm D = Driftstekniska larm USER = Användarhändelse EVEN = Systemhändelse Prioritet och kategori kombineras och presenteras i följande format och kombinationer när larmet lagras i databastabell: T1, T2, T3, D1, D2, D3 eller händelser vilka anges utan prioritet USER, EVEN. 5.4.7 FORMAT FÖR LARMNAMN (ALARMNAME) K.19. Formatet för ett larmnamn ska innehålla 20-21-tecken (inga mellanslag) och bestå av komponent-id enligt VV publikation 2007:54 plus 4 tecken enligt nedan. Totala antalet tecken beror på om länsbokstäverna NN är en bokstav (20) eller två bokstäver (21). NN+AABCC=DDDEEFFFGHHH, där NN+AABCC=DDEEFFF är komponent-id enligt VV publikation 2007:54 och GHHH enligt nedan: G =1 tecken (A=larm, H=händelse enligt VV Publikation 2007:54) HHH =3 tecken (löpnummer). Efter HHH är det fritt med tillägg. Exempel på larmnamn: AB+25193=573GL002A001 5.4.8 FORMAT FÖR MÄTNINGSNAMN (TRENDNAME) K.20. Formatet för ett mätningsnamn ska innehålla 20-21-tecken (inga mellanslag) och bestå av komponent-id enligt VV publikation 2007:54 plus 4 tecken enligt nedan. Antalet tecken beror på om länsbokstäverna NN är en bokstav (20) eller två bokstäver (21). NN+AABCC=DDDEEFFFGGGG, där NN+AABCC=DDEEFFF är komponent-id enligt VV publikation 2007:54 och GGHI kombination av tilläggsbeteckning enligt VV publikation 2007:54 och löpnummer enligt nedan: GG =2 tecken tilläggsbeteckning för processvärde två första tecknen

8 (8) H I =1 tecken sista tecken i tilläggsbeteckning eller första i löpnummer (0-9) =1 tecken sista siffran i löpnummer(1-9). Efter GGHI är det fritt med tillägg. Exempel på mätningsnamn: AB+25193=573GL002AV01 AB+25193=573GL002AVM1 Fastställd version Dokumentdatum Ändring Namn 2.0 2013-03-26 Första fastställda Joakim Frank UHaen version