RSMP Tillämpningsrekommendation signalutbyteslista

HANDLEDNING 1 (13) Skapat av (Efternamn, Förnamn, org) DokumentID Ev. ärendenummer Jonsson, Lars, Tvinit TDOK 2011:255 [Ärendenummer] Fastställt av Dokumentdatum Version [Fastställt av (personlista)] 2012-02-29 3.1.2 Dokumenttitel RSMP Tillämpningsrekommendation signalutbyteslista 1 Innehållsförteckning 1 INNEHÅLLSFÖRTECKNING... 1 2 SYFTE... 3 3 OMFATTNING... 3 4 DEFINITIONER OCH FÖRKORTNINGAR... 3 5 ANSVAR... 3 6 SIGNALUTBYTESLISTA... 3 6.1 UPPBYGGNAD OCH STRUKTUR... 3 6.1.1 Första sidan... 3 6.1.2 Objekttyper och objekt... 3 6.1.3 Objektdefinitioner... 4 6.1.4 Enskilda och grupperade objekt... 4 6.1.5 Övriga flikar... 4 6.1.6 Översikt över funktionella skillnader mellan olika meddelandetyper... 4 6.2 BEGREPPSFÖRKLARING... 5 6.2.1 Generella begrepp... 5 6.2.2 Anläggning... 5 6.2.3 Larm... 5 6.2.4 Aggregerad status... 6 6.2.5 Detaljerad status... 7 6.2.6 Styrning & Kommandon... 7 6.3 FUNKTIONELLA SAMBAND I SIGNALUTBYTESLISTAN... 7 6.3.1 Funktionslägen... 7 6.3.2 Argument och returvärden... 7 6.4 KONFIGURERBARA DATAAREOR... 9 6.4.1 Grundserie... 9 6.4.2 Utökad serie... 9 6.5 VERSIONSHANTERING... 10 6.5.1 Version av RSMP... 10 6.5.2 Revision av SUL... 10 6.6 OBLIGATORISKA SIGNALER... 11 6.6.1 Statusmeddelanden... 11 6.6.2 Styrning-/kommandomeddelanden... 11

HANDLEDNING 2 (13) 6.7 TILLÄMPNINGSREKOMMENDATION... 11 6.7.1 Definition av objekttyper... 11 6.7.2 Läsa och skriva data... 11 6.7.3 Hantering av kommunikationsavbrott... 12 7 HJÄLPMEDEL OCH REFERENSER... 12 8 ÄNDRINGSLOGG... 13

HANDLEDNING 3 (13) 2 Syfte Syftet med denna handledning är att förklara signalutbyteslistans utformning och funktion för kommunikationsprotokoll vägsidesutrustning. Handledningen fungerar som en tillämpningsrekommendation och är därmed inte kravställande. 3 Omfattning Denna handledning behandlar signalutbyteslista vilket spelar en central roll för funktionen hos kommunikationsprotokoll för vägsidesutrustning. Det rekommenderas att man tar del av denna handling för att få en djupare förståelse bl.a. inför implementation av kommunikationsprotokollet samt vid framtagning av ny signalutbyteslista. 4 Definitioner och förkortningar Samtliga definitioner som förekommer i handlingen definieras i RSMP Kommunikationsprotokoll vägsidesutrustning. 5 Ansvar Trafikverket tillhandahåller denna gränssnittsspecifikation endast som information. Trafikverket tar inte ansvar för eventuella konsekvenser som implementering av denna specifikation kan medföra för leverantören eller tredje part. 6 Signalutbyteslista Signalutbyteslistan är en viktig funktionell del av RSMP - kommunikationsprotokoll för vägsidesutrustning. Specifikation av kommunikationsprotokollet behandlas av handlingen RSMP - Kommunikationsprotokoll vägsidesutrustning. En mall av signalutbytestlistan redovisas i handlingen RSMP Mall Signalutbyteslista. Eftersom informationen i varje meddelande som skickas med kommunikationsprotokollet är dynamisk så är en fördefinierad signalutbyteslista (SUL) en förutsättning för att kunna etablera ett meddelandeflöde. Signalutbyteslistan definierar vilka meddelandetyper (signaler) som kan skickas till en viss anläggning eller objekt. Denna är uppbyggd enligt fördefinierade principer vilka redovisas nedan. 6.1 Uppbyggnad och struktur Följande underpunkter redovisar signalutbyteslistans (SUL) uppbyggnad och struktur. Underpunkternas titlar korresponderar med motsvarande namn på flikar i signalutbyteslistan. 6.1.1 FÖRSTA SIDAN Bladet med namn Första sidan definierar vilken anläggning som avses, revision av signalutbyteslistan samt datum. 6.1.2 OBJEKTTYPER OCH OBJEKT Objekttyps-fliken definierar de typer av objekt som kan förekomma i en anläggning. T.ex. Vägmärke.

HANDLEDNING 4 (13) Objektfliken redovisar de objekt som definierar den aktuella anläggningens bestyckning. Om fler än en anläggning beskrivs i SUL:en så måste en objektflik skapas för varje anläggning. Om fler än en anläggning definieras i samma SUL-dokument så döps objektfliken till anläggningens namn. Ett objekt är anpassat för att skickas till NTS om NTS-identitet (externalntsid) är definierad. 6.1.3 OBJEKTDEFINITIONER Beroende på tillämpning så kan varje objekttyp ha antingen egna serier alternativt gemensam serie.av larmsuffix (alarmcodeid), statuskoder (statuscodeid) samt styrningskoder (commandcodeid). 6.1.4 ENSKILDA OCH GRUPPERADE OBJEKT Ett objekt kan antingen sorteras in under rubriken enskilda objekt eller grupperade objekt. Ett objekt sorteras in under grupperade objekt när objektet är en komponentgrupp enl. VV:publ 2007:54 ISSN 1401-9612, övriga objekt sorteras in under enskilda objekt. Om externalntsid-fältet är ifyllt så betyder detta att objektet är anpassat för att kunna skickas till NTS. 6.1.5 ÖVRIGA FLIKAR Flikarna Larm, Aggregerad status, Status och Styrning & Kommandon korresponderar till respektive meddelandetyp som är definierade i handlingen RSMP - Kommunikationsprotokoll vägsidesutrustning, kapitel 4.1. Kursiv text som används som titel i kolumner är ej en del utav protokollet utan används endast som vägledande förklaringstext Returvärden och argument är valbara och ingen begränsning finns på hur många returvärden eller argument som kan används för ett enskilt meddelade 6.1.6 ÖVERSIKT ÖVER FUNKTIONELLA SKILLNADER MELLAN OLIKA MEDDELANDETYPER Följande tabell redovisar de funktionella skillnader mellan olika meddelandetyper. Meddelandetyp Skickas när Anpassat för att skickas vidare till NTS Larm Vid förändring Ja Aggregerad status Vid förändring Ja Status Vid förfrågan från annat system eller enl. prenumeration. (Händelsestyrt, enligt tidsintervall eller vid förändring) Nej

HANDLEDNING 5 (13) Styrning & kommando Vid förfrågan från annat system (Händelsestyrt) Ja, delvis (funktionsläge) 6.2 sförklaring Följande beskrivna begrepp förekommer som titlar för kolumner i signalutbyteslistan. Samtliga begrepp motsvaras av elementen med samma namn i grundstrukturen. 6.2.1 GENERELLA BEGREPP componentid Komponent-ID för det objekt vilket meddelandet relaterar till. 6.2.2 ANLÄGGNING siteid ntsobjectid externalntsid Anläggningsidentitet. Används för att ge möjlighet att hänvisa till en logisk benämning på en anläggning. Följande format kan användas: - Använder anläggningsdels-id från Trafikverkets komponent-id standard enl. VV:publ 2007:54 ISSN 1401-9612. T.ex. 40100. - Det går även att använda komplett komponent-id enl. VV:publ 2007:54 ISSN 1401-9612 av grupperat objekt i anläggningen utifall anläggningsdels-id är otillräckligt för att unikt särskilja en anläggning. Samtliga anläggningsidentiteter (siteid) i kommunikationsförbindelsen skickas med i meddelandet. Komponent-ID för det NTS-objekt vilket meddelandet relaterar till. Identitet för att identifiera berört NTS-objektet i kommunikation mellan NTS och andra system. Format är 5 siffror Integer. (Benämns i SL31 Object-Identity) Definieras i samråd med representanter från NTS. Unik för anläggningen. 6.2.3 LARM alarmcodeid Larmtypens unika beteckning. Exemplen i denna handling är utformade enligt följande format: Ayyy, där yyy är löpnummer.

HANDLEDNING 6 (13) description (skickas ej) externalalarmcodeid externalntsalarmcodeid stext för larm. Skickas ej i meddelandeutbytet, men definieras i SUL. (Textinnehållet är valfritt fast har följande krav: Texten definieras i samråd med Beställaren innan användning) Tillverkarspecifik larmkod och larmbeskrivning. Fabrikat, modell, larmkod och eventuell larmbeskrivning Beteckning för att identifiera larmtyp i kommunikation mellan NTS och andra system. priority category (Benämns i SL31 Alarm-Code) Meddelandets prioritet Endast följande används: 1 = larm som kräver omedelbar åtgärd. 2 = larm som inte kräver omedelbar åtgärd, men som planeras in under nästföljande arbetspass. 3 = larm som kommer att åtgärdas vid nästa planerade underhållsinsats. En bokstav, antingen T eller D. Ett larm tillhör en av två kategorier: T. Trafikala larm D. Drift/tekniska larm Trafikala larm: Utöver tekniska fellarm så finns larm som indikerar händelser i Trafiksystemet eller de tekniska processerna i en anläggning som har trafikpåverkan. Nedan exempel från en tunnel: Stillastående fordon Brandlarm Fel på budskap till trafikant Fel på bom i nedfällt läge Hög CO2 nivå i trafikrum Hög nivå i VA-anläggning Etc. Drift/tekniska larm: Skickas när det blir fel i anläggningen som inte direkt påverkar trafiken. Ett exempel på ett tekniskt fellarm är när en impulsfläkt slutar att fungera. 6.2.4 AGGREGERAD STATUS state functionalposition functionalstate (valbar) State-Bit-nr Driftstatus (se State-Bit-nr ) Funktionsläge. Visar status och styrningsmöjligheter på NTS-objekt. Motsvarar Funktionslägen Funktionsstatus. Visar för vissa NTS-objekttyper aktuell status och styrningsmöjligheter på komponenter. Driftstatus (State Bit) är ett 8-bitars binärt bitmönster som beskriver anläggningens status för NTS. Varje enskild bit kan antingen anta värdet sant ( true ) eller falskt ( false ).

HANDLEDNING 7 (13) 6.2.5 DETALJERAD STATUS statuscodeid description (skickas ej) Statusförfrågans unika beteckning. stext för statusförfrågan. Skickas ej i meddelandeutbytet, men definieras i SUL. (Textinnehållet är valfritt fast har följande krav: Texten defineras i samråd med Beställaren innan användning) 6.2.6 STYRNING & KOMMANDON commandcodeid Styrningsordens unika beteckning. Exemplen i denna handling är utformade enligt följande format: Myyy, där yyy är löpnummer. Följande tabell definierar de olika varianterna utav styrning- & kommando-meddelande. Funktionslägen Driftlägen Utformat för NTS. Tillhandahåller styrningsmöjligheter på ett NTS-objekt. För att visa status på objektet så används det motsvarande fältet functionalposition i Aggregerad status. Används ej Manöver Parameter Möjliga operatörshandgrepp på enskilda objekt eller objektgrupper från överordnat system (ej NTS). Kan även gälla automatisk styrning. T.ex. start eller stop -läge. Används för att modifiera tekniska och autonoma trafikala egenskaper hos anläggningen. 6.3 Funktionella samband i signalutbyteslistan 6.3.1 FUNKTIONSLÄGEN De funktionslägen som ett objekt kan inta ska också vara styrbara. Därför ska de styrningskoder som är definierade under Funktionslägen i Styrning & kommando -fliken också motsvara de funktionslägen som är definierade i functionalposition i Aggregerad status. 6.3.2 ARGUMENT OCH RETURVÄRDEN Argument och returvärden gör det möjligt att skicka med extra information i meddelanden. Detta gör det möjligt att skicka bl.a. binär data (base64), såsom bitmap-bilder eller liknande både till och från en anläggning eller överordnat system. Signalutbyteslistan måste tydliggöra exakt vilken datatyp som avses i varje fall. Det finns ingen begränsning på antalet argument eller returvärden som kan finnas för ett givet meddelande. Argument och returvärden redovisas som extra kolumner bredvid varje meddelade i signalutbyteslistan. Argument kan skickas med styrnings- och kommandomeddelanden Returvärden skickas med vid svar på statusförfrågan alternativt som extrainformation i larmmeddelanden.

HANDLEDNING 8 (13) Följande tabell redovisar de meddelandetyper som stödjer argument och returvärden. Meddelandetyp Argument Returvärden Larm Nej Ja Aggregerad status Nej Nej Status Nej Ja Styrning och Kommandon Ja Ja 6.3.2.1 Argument Följande tabell redovisar utformning av ett argument. name command type (skickas ej) unit (skickas ej) value Unik referens för värdet Styrkommando Värdets datatyp. Exakt definition i SUL. Definieras i SUL men skickas ej i meddelandet Generell definition: raw Värdet är uttryckt som råvärde scale Värdet är uttryckt som skalvärde unit Värdet uttryckt i enheter string Textinformation integer Numeriskt värde (16-bits signed integer), [-32768 32767] long Numeriskt värde (32-bit signed long) real Flyttal (64-bit double precision floating point) boolean Boolesk datatyp ordinal Representerar index eller nummerordning base64 Binär data uttryckt i base64-format enligt RFC-4648 Värdets enhet. Definieras i SUL men skickas ej i meddelandet Värde 6.3.2.2 Returvärde Följande tabell redovisar utformning av ett returvärde. Observera att i returvärden för statusmeddelanden så tillkommer statuscodeid och agestate, se handlingen RSMP Kommunikationsprotokoll vägsidesutrustning. name type (skickas ej) Unik referens för värdet Värdets datatyp. Definieras i SUL men skickas ej i meddelandet Generell definition: raw Värdet är uttryckt som råvärde scale Värdet är uttryckt som skalvärde unit Värdet uttryckt i enheter

HANDLEDNING 9 (13) unit (skickas ej) value string Textinformation integer Numeriskt värde (16-bits signed integer), [-32768 32767] long Numeriskt värde (32-bit signed long) real Flyttal (64-bit double precision floating point) boolean Boolesk datatyp ordinal Representerar index eller nummerordning base64 Binär data uttryckt i base64-format enligt RFC-4648 Värdets enhet. Definieras i SUL men skickas ej i meddelandet Värde från utrustning 6.4 Konfigurerbara dataareor 6.4.1 GRUNDSERIE För att skapa en möjlighet att använda en generell SUL i så hög utsträckning som möjligt så innehåller SUL i sitt standardutförande (SUL Mall) fördefinierade nummerserier för larm-, status- samt styrning/kommando-meddelanden där bl.a. datatyper i returvärden samt prioritet är fastlagda i förhand. Målet är att när det inte finns en fastlagd specifik SUL och systemen är förhållandevis friprogrammerbara förenkla arbetet med att skapa en SUL för att åstadkomma informationsutbyte. Grundserien är i första hand avsedd för små till medelstora anläggningar med begränsade behov av adresserbara nummerserier. Meddelandetyp Nummerserie Kommentar Larm A1000-A1299 Reserverade för larm med högsta prioritet (prio 1-larm) A2000-A2299 Reserverade för larm med högsta prioritet (prio 2-larm) A3000-A3299 Reserverade för larm med lägsta prioritet (prio 3-larm) Status S1000-S1299 Reserverade för returvärde av typen boolean S2000-S2299 Reserverade för returvärde av typen integer S3000-S3299 Reserverade för returvärde av typen real Styrning-/kommando M1000-M1299 Reserverade för argument av typen boolean M2000-M2299 Reserverade för argument av typen integer M3000-M3299 Reserverade för argument av typen real 6.4.2 UTÖKAD SERIE I större anläggningar kan det finnas behov att utöka nummerserierna för att täcka behoven. Därför finns det outnyttjat utrymme inom varje meddelandetyp, t.ex. prioritet 1-larm, området A1300-A1999.

HANDLEDNING 10 (13) 6.5 Versionshantering 6.5.1 VERSION AV RSMP Version av RSMP definierar den övergripande versionsnumreringen för RSMP. Samtliga dokument som ingår i RSMP-specifikationen hänvisar till version av RSMP. Följande tabell redovisar de ingående dokumenten samt deras principer vid versionsnumrering. Namn på dokument Riktlinje RSMP Kommunikationsprotokoll vägsidesutrustning Handledning RSMP Tillämpningsrekommendation signalutbyteslista Signalutbyteslista (SUL) XML-Schema (.xsd) och JSON-schema (tillhandahålls vid behov) Princip vid versionsnumrering Version av RSMP Version av RSMP Egen versionsnumrering och Version av RSMP Egen versionsnumrering vilken är baserad på version av RSMP samt löpnummer Dokumenten Riktlinje RSMP Kommunikationsprotokoll vägsidesutrustning samt Handledning RSMP Tillämpningsrekommendation signalutbyteslista följer version av RSMP, t.ex. 1.0. Signalutbyteslista (SUL) har egen versionsnumrering men vilken version av RSMP som SUL:en baseras på ska även framgå. XML-Schema och JSON-schema följer version av RSMP men inkluderar även ett valfritt löpnummer som suffix med en punkt (.) som separator, t.ex. 1.0.4. Vid ny version av RSMP så måste därför även versionsnumrering av samtliga dokument som ingår i RSMP-specifikationen uppdateras för att motsvara detta. 6.5.2 REVISION AV SUL Revision av SUL är unik för en anläggning. För att unikt identifiera en SUL från ett överordnat system måste därför anläggningens identitet (siteid) samt dess version av SUL (sxlrevision) vara känd. I varje SUL måste det även framgå vilken version av RSMP som SUL:en är baserad på. För att hantera gemensam SUL för många anläggningar där larm-, status-, styrning- /kommandomeddelanden är likadana i samtliga anläggningar i ett inledande skede men där det finns en risk att skillnader av SUL mellan anläggningar uppstår i framtiden så rekommenderas att en tabell läggs till på försättsbladet av SUL som förtydligar vilken revision av SUL som varje anläggning använder. Nedanstående tabell redovisar ett exempel för tabellens utformning: Anläggning Revision av SUL som används Anläggning 1 1.1 Anläggning 2 1.0 Anläggning 3 1.1 Syftet är att kunna uppdatera SUL med ny revision och samtidigt informera om vilka anläggningar som den nya revisionen avser.

HANDLEDNING 11 (13) 6.6 Obligatoriska signaler 6.6.1 STATUSMEDDELANDEN 6.6.1.1 Version av komponent För att försäkra att utrustning är försedd med rätt version av komponenter och för att förenkla eventuell felsökning så ska det finnas ett speciellt framtaget statusmeddelande för att efterfråga version av komponent. 6.6.1.2 Nuvarande datum och klockslag För att försäkra att utrustning är inställd med korrekt tid och datum så ska detta kunna efterfrågas med hjälp av ett statusmeddelande. Detta meddelande är i synnerhet viktigt i de implementationer där utrustningens protokollhanterare och övriga logik inte har samma klocka. Observera att UTC ska användas. 6.6.2 STYRNING-/KOMMANDOMEDDELANDEN 6.6.2.1 Ändra datum och klockslag Ifall automatisk tidssynkronisering skulle saknas eller vara ur drift så ska möjlighet ges för att ställa datum och tid manuellt med hjälp av ett styrning-/kommandomeddelanden. Observera att UTC ska användas. 6.7 Tillämpningsrekommendation För att passa olika verksamhetsområden så tillhandhålls en viss flexibilitet vid utformning av signalutbyteslista. Nedan redovisas föreslagna tillämpningsrekommendationer. 6.7.1 DEFINITION AV OBJEKTTYPER Detaljeringsgraden i definitionen av objekttyper bestämmer detaljnivån som: Meddelanden kan skickas för bl.a. larm och status Styrning-/kommandomeddelande på ingående komponenteter kan utföras Information presenteras om anläggningen för operatör/underhållspersonal i överordnat system Fördelarna med en hög noggrannhetsgrad är: Ger möjlighet till att direkt i komponentidentiteten (componentid) kunna identifiera vilket underobjekt som avses i alla meddelanden, vilket kan underlätta bl.a. uppföljning av larm Ger möjlighet till blockera larm från enskilda ingående komponenter. Fördelen med en låg noggrannhetsgrad är följande: Reducerat behov att uppdatera signalutbyteslistan vid förändring av anläggningens bestyckning Nackdelen med att inte kunna avgöra komponentidentitet som en följd av en lägre noggrannhetsgrad kan kompenseras med hjälp av argument och returvärden enligt 6.3.2. 6.7.2 LÄSA OCH SKRIVA DATA I detta protokoll rekommenderas att läs/skriv-operationer (read/write) delas upp i två olika meddelandetyper.

HANDLEDNING 12 (13) 6.7.2.1 Läsoperationer För läsoperationer (read) så rekommenderas status-meddelanden. Förlopp för en läsoperation: 1. När data ska läsas skickas ett statusmeddelande från överordnat system/annan anläggning till efterfrågad anläggning. 2. Anläggningen svarar därefter med att skicka tillbaka det värdet från utrustningen (med hjälp av motsvarande svarsmeddelande). Anläggningens värde bifogas som ett returvärde. 6.7.2.2 Skrivoperationer För skrivoperationer (write) så rekommenderas styrning-/kommandomeddelanden. Dessa fungerar som s.k. bör -värden. Förlopp för en skrivoperation: 1. När data ska skrivas så skickas ett styrning-/kommandomeddelande från överordnat system/annan anläggning till efterfrågad anläggning. Det nya värdet bifogas i meddelandet som ett argument. 2. Anläggningen svarar därefter med att skicka tillbaka det nya värdet från utrustningen (med hjälp av motsvarande svarsmeddelande). Anläggningens värde bifogas som ett returvärde. 3. Överordnat system/annan anläggningen jämför vad den skickade med det som rapporteras från anläggningen och kan därmed avgöra på huruvida det nya värdet kunde appliceras eller ej. 6.7.3 HANTERING AV KOMMUNIKATIONSAVBROTT För att kunna effektivt hantera exempelvis kommunikationsavbrott, strömavbrott eller initialt uppstartsförfarande där bl.a. larmstatus, aggregerad status och detaljerad status är sen tidigare okända av överordnat system så rekommenderas nedanstående uppsättning meddelanden att läggas till i signalutbyteslistan: Ett styrnings-/kommandomeddelande för att begära att anläggningen skickar larmstatus för samtliga ingående objekt Ett styrnings-/kommandomeddelande för att begära att anläggningen skickar aggregerad status för samtliga NTS-objekt Ett styrnings-/kommandomeddelande för att begära att anläggning skickar all relevant statusinformation i ett och samma svarsmeddelande (med hjälp av argument) 7 Hjälpmedel och referenser RSMP Kommunikationsprotokoll vägsidesutrustning RSMP Mall Signalutbyteslista

HANDLEDNING 13 (13) 8 Ändringslogg Fastställd version Dokumentdatum Ändring Namn 1.0 2011-05-20 Dokumentet upprättat DO 3.0 2011-11-04 Konfigurerbara DO dataareor samt versionshantering tillagt 3.1.1 2011-12-23 Mindre revidering DO 3.1.2 2012-02-29 Mindre revidering DO