RSMP Kommunikationsprotokoll vägsidesutrustning

Transkript

1 RIKTLINJE 1 (55) Skapat av (Efternamn, Förnamn, org) DokumentID Ev. ärendenummer Jonsson Lars, Tvinit TDOK 2011:256 [Ärendenummer] Fastställt av Dokumentdatum Version [Fastställt av] Dokumenttitel RSMP Kommunikationsprotokoll vägsidesutrustning 1 Innehållsförteckning 1 INNEHÅLLSFÖRTECKNING DEFINITIONER INLEDNING BAKGRUND SYFTE IDENTIFIERADE BEHOV TILLÄMPNING OMFATTNING Ansvar OBJEKTMODELL TRANSPORT AV DATA Säkerhet Etablering av kommunikation mellan anläggning och överordnat system Etablering av kommunikation mellan anläggningar Kommunikationsavbrott Transport mellan anläggning och överordnat system Transport mellan anläggningar GRUNDSTRUKTUR Larmmeddelanden Aggregerad status -meddelanden Statusmeddelanden Styrnings- och kommandomeddelanden Kvittering på att meddelande mottagits RSMP/SXL Version Watchdog TILLÄMPNING AV JSON Motsvarighet av termer Wrapping av paket Larmmeddelanden Aggregerad status -meddelande Statusmeddelanden Styrnings- och kommandomeddelanden Kvittering på att meddelande mottagits RSMP/SXL Version... 53

2 RIKTLINJE 2 (55) Watchdog ÄNDRINGSLOGG... 55

3 RIKTLINJE 3 (55) 2 Definitioner Begrepp SXL NTS TLC Maximo ITS-anläggning Anläggning Lokal vägsidesutrustning Överordnat system Objekt Betydelse Signalutbyteslista Nationellt TrafikledningsStöd. System för trafikledningscentral. Ersätter CTS Trafikledningscentral Trafikverkets stödsystem för drifthantering Lokal vägsidesutrustning. Innefattar både fältnivå och lokalnivå Se ITS-anläggning Se ITS-anläggning Övervaknings- och styrsystem på regional- och/eller nationell nivå Ett objekt är ett abstrakt begrepp som existerar i styr- och övervakningssystem. Ett objekt har en eller flera status som kan ändras på grund av förändringar inom objektet eller genom styrning av objektet utifrån. Kommunikation med objektet sker genom utbyte av signaler för t.ex. styrning, status- och larmrapportering. Objekt kan motsvaras av en fysisk utrustning t.ex. en kamera, men kan också vara ett abstrakt ting såsom en algoritm. Aggregerat objekt Ett objekt identifieras av objektets komponent-id. Observera att objekt ej är samma sak som NTS-objekt. Avser gruppering av flera andra objekt, en så kallad komponentgrupp (component group (CG)). Objekttyp NTS-Objekt En objekttyp är en klassificering av objekt som styr ett antal egenskaper hos de objekt som tillhör samma objekttyp. Objekttypen styr bland annat hur objektet visas i styr och övervakningssystemet, hur det grupperas och vilka funktionslägen, larmkoder, händelser och mätningar som är möjliga. Avser objekt i NTS. Alla styr- och övervakningsfunktioner i NTS är uppbyggd kring NTSobjekt. Ett NTS-objekt kan representera ett eller flera objekt NTS-objekt identifieras i kommunikationsgränssnitt via det som i RSMP benämns externalntsid. Detta då gränssnittet mot NTS ej kan hantera det format som används för komponent-id NTS-objekt och objekt kan ha samma komponent-id

4 RIKTLINJE 4 (55) NTS-Objekttyp Komponent Komponent-ID XML JSON TCP/IP W3C DATEX II RSMP En NTS-objekttyp är en klassificering av NTS-objekt. Styr bland annat vilka funktionslägen som är möjliga för NTS-objektet. Avser objekt eller NTS-objekt. Komponenter betecknas med komponent-id. Avser komponentidentitet enligt Trafikverkets publikation 2012:1171 Komponent-ID är på format AA+BBCDD=EEEFFGGG. extensible Markup Language JavaScript Object Notation Transfer Control Protocol/Internet Protocol World Wide Web Consortium Europeisk standard för meddelandeutbyte mellan trafikala system. ( Road Side Message Protocol

5 RIKTLINJE 5 (55) 3 Inledning Detta dokument redovisar ett generellt protokoll för kommunikation mellan överordnade system och anläggningar samt kommunikation direkt mellan anläggningar. Syftet är att kunna erbjuda ett standardiserat protokoll som fungerar på samma sätt oavsett leverantör eller typ av anläggning. 3.1 Bakgrund Historisk har Trafikverket haft en regional organisationsstruktur som ansvarat för upphandling och förvaltning av tekniska system, inklusive ITS-anläggningar. Detta har inneburit att olika regioner har haft olika krav på funktionalitet och gränssnitt mot överordnade system. Trafikverket har dessutom varit beroende av teknikområdes- och leverantörsspecifika kommunikationsprotokoll, vilket lett till begränsade möjligheter att samordna förvaltning och drift mellan olika teknikområden och regioner. Trafikverket har idag en nationell organisation för förvaltning av tekniska anläggningar och system. Inom denna organisation ligger ansvar för att skapa en enhetlig struktur och kravbild på Trafikverkets tekniska system. Detta för att: Underlätta införande, förvaltning och drift av anläggningar Underlätta för leverantörsmarknaden att ta fram koncept och lösningar som fungerar nationellt och inte kräver regionala anpassningar. På detta sätt ges förutsättningar att uppnå en enhetlig funktionalitet mot trafikant, drift- och underhåll, förvaltning och trafikledningscentral. I förlängningen kan Trafikverket på detta sätt få bättre effekt av gjorda investeringar. För att skapa en långsiktigt hållbar systempark som är uppgraderingsbar och skalbar har nedanstående grova systemarkitektur tagits fram. Arkitekturen bygger på att man skapar ett antal nivåer med väldefinierade gränssnitt mot överliggande, respektive underliggande nivå. På detta sätt kan man införa ny funktionalitet, uppgradera eller byta ut ett system på respektive nivå utan att påverka andra system eller verksamheter. Figur 1. Principiell systemarkitektur

6 RIKTLINJE 6 (55) 4 Syfte Syftet med detta protokoll är att skapa ett standardiserat sätt att kommunicera mellan system på lokalnivå och system på regionalnivå oavsett leverantör och teknikområde. Målet är att enkelt kunna lägga till och ta bort signaler i nya anläggningar och applikationer utan att behöva utöka eller förändra standarder och riktlinjer. Detta innebär att protokollet, till skillnad mot många andra standarder och protokoll, inte omfattar detaljinformation om signalutbytet utan är inriktat på att definiera signaltyper som sedan beskrivs anläggnings- eller objektsspecifikt. Målsättningen är att man på sikt, baserat på installerade anläggningar och objekt, får fram ett erfarenhetsbaserat signalutbyte för typobjekt som kan återanvändas i nya upphandlingar så att larmtexter, kommandon etc. får samma benämning oavsett anläggning eller leverantör. Syftet med signalutbytet som ska skickas via detta kommunikationsprotokoll är bl.a. att kommunicera information som berör exempelvis trafikledare, driftledare och förvaltare. Det vill säga information som behövs för att övervaka och styra anläggningen, samt information som kan användas för statistik och analys av trafik- och anläggningsstatus. Exempelvis ska fellarm innehålla tillräcklig information för att kunna lägga en arbetsorder i Maximo som sedan skickas till driftentreprenör, dvs. tillräcklig information om vilken typ av kompetens och utrustning som krävs för att åtgärda felet. Detaljinformation om ett larm (ex. vilket I/O-kort som gått sönder, vilken LED-kedja som är ur funktion, etc.) avläses på plats via leverantörsspecifik webbgränssnitt eller operatörspanel. 4.1 Identifierade behov För att åstadkomma ett teknikområdes och leverantörsoberoende informationsutbyte har fyra meddelandetyper identifierats för att täcka all tänkbar information som Trafikverket har behov av. Informationen i respektive meddelandetyp är dynamisk och definieras per anläggningstyp eller specifik anläggning i en specifik signalutbyteslista (SXL). Denna lista utgör även gränssnittet mellan överordnat system/andra anläggningar och en anläggning. De fyra meddelandetyperna är: Larm, trafikala eller drifttekniska händelser som kräver åtgärd från trafik- eller driftingenjör. Skickas från anläggning till överordnat system vid uppkomst Aggregerad status. En aggregerad status som ger en översikts bild av anläggningens status. Skickas från anläggning vid förändring eller vid uppkoppling mot överordnat system/annan anläggning Status, statusförändringar, indikeringar och detaljerad information som ska loggas eller synliggöras på överordnad nivå. Skickas vid förfrågan från överordnat system/annan anläggning eller via prenumeration - antingen vid förändring av status eller enl. tidsintervall Styrning och kommandon, skickas från överordnat system eller annan anläggning för att förändra anläggningens/objektets status eller styrprincip För mer information om meddelandetypernas uppbyggnad, se avsnitt 5.4.

7 RIKTLINJE 7 (55) 5 Tillämpning 5.1 Omfattning Dokumentet är en generisk gränssnittsspecifikation för RSMP-gränssnittet som beskriver protokollets överföringsmekanismer och funktion. Dokumentet är en specifikation som tillåter många tillämpningar inom och utom Trafikverket. Dokumentet vänder sig till de som har behov av att implementera ett RSMP-gränssnitt ANSVAR Trafikverket tillhandahåller denna gränssnittsspecifiktion endast som information. Trafikverket tar inte ansvar för eventuella konsekvenser som implementering av specifikationen kan medföra för leverantören eller tredje part. 5.2 Objektmodell Detta protokoll använder sig av Datex II (datex2.eu) metamodell för sin objektmodell. Metamodellen består av ett antal regler för att beskriva hur klasser och objekt ska definieras. Anledningen till att man valt att använda sig av Datex II metamodell är att man på sikt ska kunna gå vidare med detta protokoll till en internationell standard som senare kan inkluderas objektmodellen för Datex II. Protokollets objektmodell är teknikoberoende d.v.s. kan implementeras på olika sätt t.ex. med hjälp av ASN.1, JSON eller XML. I kapitel 5.4 redovisas samtliga exempel i XML-format för tydlighetens skull. Men vid kommunikation mellan anläggning och överordnade system/annan anläggning så ska JSON-format användas. I kapitel 5.5 redovisas alla meddelandetyper i både XML och JSON sida vid sida. Objekt som används för meddelandeutbyte är Alarm med underklasserna Issue, Acknowledge och Suspend. För övriga objekt finns klasserna AggregatedStatus, StatusRequest, StatusResponse, CommandRequest, CommandResponse, Watchdog, MessageAck, MessageNotAck. För utförlig information om hur dessa klasser används se kapitel 5.4 Grundstruktur.

8 RIKTLINJE 8 (55) 5.3 Transport av data Meddelandeflödet skiljer mellan olika typer av meddelanden. Vissa meddelanden är händelsestyrda och skickas utan att de efterfrågas (push), medan andra är interaktionsstyrda, dvs. de skickas som svar på en förfrågan från överordnat system eller annan anläggning (client-server). För att säkerställa att meddelanden kommer fram till sin mottagare så inkluderas meddelandekvittering på alla meddelanden som skickas. Detta ger applikationen ett enkelt sätt att följa upp meddelandeutbytet. För att kommunicera mellan anläggningar och överordnat system/annan anläggning så används en ren TCP-anslutning (i TCP/IP), och data som skickas bygger på JSON-format, det vill säga formaterad text. Meddelanden kan skickas asynkront. D.v.s. under tiden som ena anläggningen/systemet väntar på svar kan andra meddelanden skickas och tas emot av den andra anläggningen/systemet SÄKERHET Anslutningar med RSMP skall skyddas med kryptering om Beställaren kräver detta. Både överordnade system och anläggningar skall ha möjligheten att enkelt aktivera/inaktivera kryptering. För krypterad kommunikation används SSL 3.0/TLS 1.0 eller senare. Certifikat används för att styrka identiteter av utrustning. Utrustning som använder RSMP skall innehålla gränssnitt för enkel hantering av certifikat. Utfärdande samt förnyande av certifikat utförs av Beställaren. Installation av certifikat utförs i samråd med Beställaren om inget annat är överenskommet ETABLERING AV KOMMUNIKATION MELLAN ANLÄGGNING OCH ÖVERORDNAT SYSTEM Vid etablering av kommunikation skickas meddelanden i följande turordning. Figur 1: Meddelandeförlopp (MessageAck är implicit)

9 RIKTLINJE 9 (55) 1. RSMP/SXL-version (enl. kapitel 5.4.6). Verifikation av RSMP-version, SXL-version och anläggnings-id sker 2. Watchdog (enl. kapitel 5.4.7) 3. Aggregerad status (enl. kapitel 5.4.2) 4. Samtliga aktiva och blockerade larm skickas (enl. kapitel 5.4.1) 5. Eventuella kvarliggande meddelanden i utrustningens utgående kommunikationsbuffert skickas Eftersom endast en version av signalutbyteslistan är tillåten vid upprättande av kommunikation (enligt versionsmeddelande) så måste samtliga anslutna anläggningar antingen: Använda samma version av signalutbyteslista via gemensam kommunikationsförbindelse för samtliga anläggningar till överordnat system Använda olika signalutbyteslistor med hjälp av separata kommunikationsförbindelser. Överordnat system måste i detta fall lyssna på separata port-nummer en för varje signalutbyteslista (dvs. anläggning). Detta krävs i de fall då man önskar ha möjligheten att uppdatera signalutbyteslistan för en anläggning utan att påverka signalutbyteslistan för övriga anläggningar ETABLERING AV KOMMUNIKATION MELLAN ANLÄGGNINGAR 1. RSMP/SXL-version (enl. kapitel 5.4.6). Verifikation av RSMP-version, SXL-version och anläggnings-id sker 2. Watchdog (enl. kapitel 5.4.7) 3. Aggregerad status (enl. kapitel 5.4.2). Figur 2: Meddelandeförlopp (MessageAck är implicit) För kommunikation mellan anläggningar så gäller: Anläggningsidentiteten siteid som skickas i RSMP/SXL-version är anslutande anläggningens egna siteid Om anläggnings-id (siteid) inte stämmer överens med den förväntade anläggnings-id hos den andra anläggningen så skall anslutningen stängas ner. Syftet är att minska risken att etablera anslutning med fel anläggning. Detta innebär att båda anläggningarna måste veta siteid hos den andra apparaten Komponent-id (componentid) som används i alla meddelanden är den anslutande anläggningens komponent-id. Watchdog-meddelanden justerar ej tiden (se kapitel 5.4.7) Larmmeddelanden skickas ej (se kapitel 5.4.1) Ingen kommunikations-buffert existerar

10 RIKTLINJE 10 (55) KOMMUNIKATIONSAVBROTT Vid händelse av kommunikationsavbrott så lagras utgående meddelanden i utrustningens kommunikationsbuffert. Så snart kommunikationen är återupprättad så skickas samtliga meddelanden i kommunikationsbufferten. Samtliga meddelandetyper skall buffras, men undantag för watchdog-meddelanden. Som standard så skall eventuella prenumerationer på statusmeddelanden bibehållas även under kommunikationsavbrott så att dessa data kan skickas vid kommunikationens återetablering. Vid händelse av kommunikationsavbrott eller strömavbrott får utgående kommunikationsbuffert hos utrustning ej tömmas, Den interna kommunikationsbufferten hos utrustningen måste som minimum vara dimensionerad till att kunna lagra meddelanden. Vid full kommunikationsbuffert ska FIFO-princip tillämpas. Följande inställningar skall finnas hos anläggningen - Anläggningen skall försöka återansluta till överordnat system/annan anläggning vid kommunikationsavbrott (ja/nej). Denna inställning skall vara aktiverad som standard såvida inte goda skäl föreligger. - Frekvensen mellan återanslutningsförsök om anslutningen bryts. Som standard rekommenderas denna inställning ställas till tio (10) sekunder TRANSPORT MELLAN ANLÄGGNING OCH ÖVERORDNAT SYSTEM Överordnat system agerar server, och väntar på att anläggning ska ansluta sig. Skulle kommunikationen fallera så är det anläggningens ansvar att koppla upp sig igen TRANSPORT MELLAN ANLÄGGNINGAR Ena anläggningen agerar server, och väntar på att en annan anläggning ska ansluta sig. Skulle kommunikationen fallera så är det den anslutande anläggningens ansvar att koppla upp sig igen. 5.4 Grundstruktur För alla meddelanden används teckenuppsättningen Unicode (ISO 10646) och kodning enligt UTF-8. Samtliga meddelanden ser ut på följande sätt i sin grundläggande form. Fet text innebär variabelt innehåll, t.ex. meddelandeinformation, status, identitet och tidpunkt. Övrig text är del av meddelandets grundstruktur. <?xml version="1.0" encoding="utf-8"?> <roadsidemessage modelbaseversion="1.0" xmlns=" xsi:schemalocation=" RoadSideMessage_1_0_1_4.xsd"> <message xsi:type="alarm"> <messageid>{e68a0010-c336-41ac-bd58-5c80a72c7092}</messageid> <ntsobjectid>f+40100=416cg100</ntsobjectid> <externalntsid>23055</externalntsid> <componentid>ab+84001=860va001</componentid>

11 RIKTLINJE 11 (55) XML-kod 1: Grundstruktur för ett XML-meddelande. I detta exempel så är meddelandetypen satt som larmmeddelande Följande tabell beskriver tillåtet innehåll i meddelandet. Element Värde Beskrivning messageid (GUID) Meddelandeidentitet. Genereras som ett GUID (Globally unique identifier) i den utrustningen som skickade meddelandet. Endast version 4 av Leach-Salz UUID används. Används som referens för meddelandekvitteringen ntsobjectid (valbar) (enl. SXL) Komponent-ID för det NTS-objekt vilket meddelandet relaterar till. externalntsid (valbar) (enl. SXL) 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. componentid (enl. SXL) Komponent-ID för det objekt vilket meddelandet relaterar till.

12 RIKTLINJE 12 (55) LARMMEDDELANDEN Ett larmmeddelande skickas till överordnat system när Ett larm blir aktivt/inaktivt Ett larm kvitteras Blockering av larm aktiveras eller avaktiveras Kvittering av larm innebär att den berörda larmkoden för ett visst objekt kvitteras. Om ett larm är från början inaktivt men blir aktivt så blir larmet också automatiskt icke-kvitterat. Larmkoden äger statusen på huruvida larmet har blivit kvitterat eller ej. D.v.s. om ett larm blir aktivt, inaktivt och sedan aktivt igen utan att det blev kvitterat däremellan - så behöver larmet endast kvitteras en gång och inte för varje gång larmet blev aktivt. Detta förhållningssätt förenklar både vid implementering men även vid hantering utifall många larm skulle inträffa på samma utrustning med kort tidsintervall. Vid larmblockering så blockeras larmmeddelanden med avseende på ett visst objekt och dess larmkod. Uppdatering av objektet sker fortfarande med avseende på andra till objektet knutna larm. Larmmeddelanden är händelsestyrda och skickas till överordnat system när larm inträffar. Kvitteringsmeddelanden och blockeringsmeddelanden är interaktionsstyrda Meddelandestruktur Struktur för larmmeddelande Larmmeddelande har samma utformning när det skickas oavsett huruvida meddelandet är ett resultat av att ett larm inträffar, kvitteras eller blockeras; med undantag för taggen alarmspecialisation. Följande tabell förklarar skillnaden: Element och värde <alarmspecialisation xsi:type= Issue > <alarmspecialisation xsi:type= Acknowledge > <alarmspecialisation xsi:type= Suspend > Betydelse Ett larm blir aktivt/inaktivt Ett larm kvitteras Blockering av ett larm aktiveras eller deaktiveras Ett larmmeddelande är utformat enligt nedan. Fet text innebär variabelt innehåll, t.ex. meddelandeinformation, status, identitet och tidpunkt. Övrig text är del av meddelandets grundstruktur. <roadsidemessage modelbaseversion="1.0" xmlns=" xsi:schemalocation=" RoadSideMessage_1_0_1_4.xsd"> <message xsi:type="alarm"> <messageid>{e68a0010-c336-41ac-bd58-5c80a72c7092}</messageid> <ntsobjectid>f+40100=416cg100</ntsobjectid> <externalntsid>23055</externalntsid> <componentid>ab+84001=860va001</componentid> <alarmcodeid>a001</alarmcodeid>

13 RIKTLINJE 13 (55) <externalalarmcodeid>lampfel på lykta 1 (röd)</externalalarmcodeid> <externalntsalarmcodeid>3143</externalntsalarmcodeid> <alarmspecialisation xsi:type="issue"> <acknowledgestate>notacknowledged</acknowledgestate> <alarmstate>active</alarmstate> <suspendstate>notsuspended</suspendstate> <timestamp> t11:59:31.571z</timestamp> <category>t</category> <priority>2</priority> <returnvalues> <returnvalue> <name>signalgrupp</name> <value>1</value> </returnvalue> <returnvalue> <name>färg</name> <value>röd</value> </returnvalue> </returnvalues> </alarmspecialisation> XML-kod 2: Ett larmmeddelande som indikerar ett lampfel hos anläggning AB+84001=860VA001. Följande tabeller beskriver tillåtet innehåll i meddelandet Huvuddel (xsi:type = Alarm) Element Värde Beskrivning alarmcodeid (enl. SXL) Larmsuffix som tillsammans med komponent-id identifierar larmet i anläggningen. Den exakta utformningen bestäms av signalutbyteslistan (SXL). Exemplen i denna handling är utformade enligt följande format: Ayyy, där yyy är löpnummer. externalalarmcodeid (valbar) externalntsalarmcodeid (valbar) Larmstatus (tillverkarspecifik) (enl. SXL) Tillverkarspecifik larmkod och larmbeskrivning. Fabrikat, modell, larmkod och eventuell larmbeskrivning Larmkod för att identifiera larmtyp i kommunikation mellan NTS och andra system. (Benämns i SL31 Alarm-Code) Element Värde Beskrivning acknowledegestate acknowledged larmet är kvitterat notacknowledged larmet är ej kvitterat alarmstate inactive larmet är inaktivt active larmet är aktivt suspendstate suspended larm är blockerade notsuspended larm är ej blockerade timestamp (tidsstämpel) Tidsstämpel för antingen när larmet inträffar, kvitteras eller blockeras. Se innehållet i

14 RIKTLINJE 14 (55) alarmspecialisation för vilken tidsstämpel som avses. category T D Tidsstämpling enligt W3C XML datetimedefinition med en noggrannhet på 3 decimaler. Tidsstämplingen sker i anläggning och gäller för då larmet inträffar. All tidsstämpling anges i UTC. 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. description (skickas ej) (enl. SXL) 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. Beskrivningstext för larm. Skickas ej i meddelandeutbytet, men definieras i SXL. (Textinnehållet är valfritt fast har följande krav: Texten är specifik för typen av objekt Texten definieras i samråd med Beställaren innan användning) priority [0-9] 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 Eventuella returvärden (returnvalue) Element Värde Beskrivning name (enl. SXL) Unik referens för värdet type (skickas ej) (enl. SXL) Värdets datatyp. Definieras i SXL men skickas ej i meddelandet Generell definition: string Textinformation integer Numeriskt värde (16-bit signed integer), [ ]

15 RIKTLINJE 15 (55) long Numeriskt värde (32-bit signed long) real Flyttal (64-bit double precision floating point) boolean Boolesk datatyp (True/False) base64 Binär data uttryckt i base64-format enligt RFC-4648 Punkt (. ) används alltid som decimalavgränsare unit (skickas ej) (enl. SXL) Värdets enhet. Definieras i SXL men skickas ej i meddelandet value (enl. SXL) Värde från utrustning Struktur för larmkvitteringsmeddelande Ett larmkvitteringsmeddelande är utformat enligt nedan. Fet text innebär variabelt innehåll, t.ex. meddelandeinformation, status, identitet och tidpunkt. Övrig text är del av meddelandets grundstruktur. <roadsidemessage modelbaseversion="1.0" xmlns=" xsi:schemalocation=" RoadSideMessage_1_0_1_4.xsd"> <message xsi:type="alarm"> <messageid>{e68a0010-c336-41ac-bd58-5c80a72c7092}</messageid> <ntsobjectid>f+40100=416cg100</ntsobjectid> <externalntsid>23055</externalntsid> <componentid>ab+84001=860va001</componentid> <alarmcodeid>a001</alarmcodeid> <externalalarmcodeid>larmfel på lykta 1 (röd)</externalalarmcodeid> <externalntsalarmcodeid>3143</externalntsalarmcodeid> <alarmspecialisation xsi:type="acknowledge" /> XML-kod 3: Ett larmkvitteringsmeddelande som kvitterar larm Följande tabeller beskriver tillåtet innehåll i meddelandet Huvuddel (xsi:type = Alarm) Element Värde Beskrivning alarmcodeid (enl. SXL) Larmsuffix som tillsammans med komponent-id identifierar larmet i anläggningen. Den exakta utformningen bestäms av signalutbyteslistan (SXL). Exemplen i denna handling är utformade enligt följande format: Ayyy, där yyy är löpnummer. externalalarmcodeid (valbar) externalntsalarmcodeid (valbar) (tillverkarspecifik) (enl. SXL) Tillverkarspecifik larmkod och larmbeskrivning. Fabrikat, modell, larmkod och eventuell larmbeskrivning Larmkod för att identifiera larmtyp i kommunikation mellan NTS och andra system.

16 RIKTLINJE 16 (55) (Benämns i SL31 Alarm-Code) Larmkvittering (xsi:type = Acknowledge) (inget innehåll) Struktur för larmblockeringsmeddelande Ett larmblockeringsmeddelande är utformat enligt nedan. Fet text innebär variabelt innehåll, t.ex. meddelandeinformation, status, identitet och tidpunkt. Övrig text är del av meddelandets grundstruktur. <roadsidemessage modelbaseversion="1.0" xmlns=" xsi:schemalocation=" RoadSideMessage_1_0_1_4.xsd"> <message xsi:type="alarm"> <messageid>{e68a0010-c336-41ac-bd58-5c80a72c7092}</messageid> <ntsobjectid>f+40100=416cg100</ntsobjectid> <externalntsid>23055</externalntsid> <componentid>ab+84001=860va001</componentid> <alarmcodeid>a001</alarmcodeid> <externalalarmcodeid>larmfel på lykta 1 (röd)</externalalarmcodeid> <externalntsalarmcodeid>3143</externalntsalarmcodeid> <alarmspecialisation xsi:type="suspend"> <suspendaction>suspend</suspendaction> </alarmspecialisation> XML-kod 4: Ett larmblockeringsmeddelande i syfte att blockera larm för utrustning Följande tabeller beskriver tillåtet innehåll i meddelandet Huvuddel (xsi:type = Alarm) Element Värde Beskrivning alarmcodeid (enl. SXL) Larmsuffix som tillsammans med komponent-id identifierar larmet i anläggningen. Den exakta utformningen bestäms av signalutbyteslistan (SXL). Exemplen i denna handling är utformade enligt följande format: Ayyy, där yyy är löpnummer. externalalarmcodeid (valbar) externalntsalarmcodeid (valbar) (tillverkarspecifik) (enl. SXL) Tillverkarspecifik larmkod och larmbeskrivning. Fabrikat, modell, larmkod och eventuell larmbeskrivning Larmkod för att identifiera larmtyp i kommunikation mellan NTS och andra system. (Benämns i SL31 Alarm-Code)

17 RIKTLINJE 17 (55) Larmblockering (xsi:type = Suspend) Element Värde Beskrivning suspendaction suspend Aktivera blockering av larm resume Deaktivera blockering av larm Meddelandeutbyte mellan anläggning och överordnat system Kvittering på att meddelanden mottagits (enl. kapitel 5.4.5) är implicit i nedanstående figurer Ett larm blir aktivt/inaktivt 1 Ett larmmeddelande skickas till överordnat system med larmets status (att larmet är aktivt/inaktivt) Ett larm kvitteras från överordnat system 1 Ett kvitteringsmeddelande skickas ner till anläggningen 2 Ett larmmeddelande skickas till överordnat system med larmets status (att kvittering är utförd)

18 RIKTLINJE 18 (55) Ett larm kvitteras från anläggning 1 Ett larmmeddelande skickas till överordnat system med larmets status (att kvittering är utförd) Ett larm blockeras/avblockeras från överordnat system 1 Ett blockeringsmeddelande skickas ner till anläggningen 2 Ett larmmeddelande skickas till överordnat system med larmets status (att blockering/avblockering är utförd) Ett larm blockeras/avblockeras från anläggning

19 RIKTLINJE 19 (55) 1 Ett larmmeddelande skickas till överordnat system med larmets status (att blockering/avblockering är utförd) AGGREGERAD STATUS -MEDDELANDEN Denna typ av meddelande skickas till överordnat system och annan anläggning för att informera om anläggningens status. "Aggregerad status"-meddelanden är händelsestyrda och skickas när driftstatus, funktionsläge eller funktionsstatus ändras i anläggningen Meddelandestruktur Ett "aggregerad status"-meddelande är utformat enligt nedan. Fet text innebär variabelt innehåll, t.ex. meddelandeinformation, status, identitet och tidpunkt. Övrig text är del av meddelandets grundstruktur. <roadsidemessage modelbaseversion="1.0" xmlns=" xsi:schemalocation=" RoadSideMessage_1_0_1_4.xsd"> <message xsi:type="aggregatedstatus"> <messageid>{e68a0010-c336-41ac-bd58-5c80a72c7092}</messageid> <ntsobjectid>f+40100=416cg100</ntsobjectid> <externalntsid>23055</externalntsid> <componentid>f+40100=416cg100</componentid> <aggstatustimestamp> t14:34:34.345z</aggstatustimestamp> <aggregatedstatusspecialisation> <functionalposition>trafikstyrning</functionalposition> <functionalstate>automatiskt nedsatt hastighet</functionalstate> <state> <name>1</name> <state>false</state> </state> <state> <name>2</name> <state>true</state> </state>

20 RIKTLINJE 20 (55) <state> <name>3</name> <state>true</state> </state> <state> <name>4</name> <state>false</state> </state> <state> <name>5</name> <state>false</state> </state> <state> <name>6</name> <state>false</state> </state> <state> <name>7</name> <state>false</state> </state> <state> <name>8</name> <state>false</state> </state> </aggregatedstatusspecialisation> XML-kod 5: Ett aggregerad status -meddelande i syfte att informera om att anläggning har bytt funktionsläge, funktionsstatus och/eller driftstatus Följande tabeller beskriver tillåtet innehåll i meddelandet Huvuddel (aggregatedstatus) Element Värde Beskrivning aggstatustimestamp (tidsstämpel) Tidsstämpling enligt W3C XML datetimedefinition med en noggrannhet på 3 decimaler. Tidsstämplingen sker i anläggning och gäller för då statusen hämtas. All tidsstämpling anges i UTC Aggregerad status (aggregatedstatusspecialisation) Element Värde Beskrivning functionalposition (enl. SXL) Funktionsläge functionalstate (valbar) (enl. SXL) Funktionsstatus state (se nedan) Driftstatus (se nedan)

21 RIKTLINJE 21 (55) Driftstatus (state) 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 ). Element Värde Beskrivning state true false Driftstatus (State Bit) name [1-8] Bit nr (heltal mellan 1 och 8) Princip för aggregering av status för varje enskild bit definieras av tillhörande kommentarer i signalutbyteslista (SXL). Generell beskrivning av varje enskild bit redovisas i följande tabell Element Bit (name) Beskrivning state 1 Anläggningen tagit ur drift av lokalt styrsystem eller underhållspersonal är ute vid objektet. 2 Överordnat system har ingen kontakt med anläggningen 3 Anläggningen har ett larm som kräver omedelbar åtgärd. (Prioritet 1) 4 Anläggningen har ett larm som inte kräver omedelbar åtgärd, men som planeras in under nästföljande arbetspass. (Prioritet 2) 5 Anläggningen har ett larm som kommer att åtgärdas vid nästa planerade underhållsinsats. (Prioritet 3) 6 Anläggningen är anslutet och används för närvarande. 7 Anläggningen är anslutet men används inte för stunden 8 Anläggningen är inte anslutet till överordnat system. Status i överordnat Ljusblå lokal styrning Lila Kommunikationen bruten Röd Högprioriterat fel Gul Medelprioriterat fel Blå Lågprioriterat fel Grön - Normal drift - används Mörkgrå - vila Ljusgrå Ej ansluten Meddelandeutbyte mellan anläggning och annan anläggning/överordnat system Kvittering på att meddelanden mottagits (enl. kapitel 5.4.5) är implicit i nedanstående figur.

22 RIKTLINJE 22 (55) (Driftstatus, funktionsstatus eller funktionsläge ändrar sig i anläggning) 1 Ett "Aggregerad status"-meddelande skickas till överordnat system/annan anläggning STATUSMEDDELANDEN Statusmeddelande är ett typ av meddelande som skickas till överordnat system eller annan anläggning med status på ett eller flera förfrågade objekt. Statusmeddelande kan vara både interaktions- och händelsestyrt och kan skickas vid följande villkor: När status efterfrågas från överordnat system/annan anläggning. Enligt prenumeration antingen vid fast tidsintervall eller vid statusens förändring Meddelandestruktur Struktur för meddelande med förfrågan på status för ett eller flera objekt Ett meddelande med förfrågan om status är utformat enligt nedan. Fet text innebär variabelt innehåll vilket kan ändras beroende på lokala omständigheter. Övrig text är del av meddelandets grundstruktur. <roadsidemessage modelbaseversion="1.0" xmlns=" xsi:schemalocation=" RoadSideMessage_1_0_1_4.xsd"> <message xsi:type="statusrequest"> <messageid>{e68a0010-c336-41ac-bd58-5c80a72c7092}</messageid> <ntsobjectid>f+40100=416cg100</ntsobjectid> <externalntsid>23055</externalntsid> <componentid>ab+84001=860va001</componentid> <statuses> <status> <statuscodeid>s003</statuscodeid> <name>speed</name> </status>

23 RIKTLINJE 23 (55) <status> <statuscodeid>s003</statuscodeid> <name>occupancy</name> </status> </statuses> XML-kod 6: En statusförfrågan i syfte att begära aktuellt värde på efterfrågat objekt Följande tabeller beskriver tillåtet innehåll i meddelandet Huvuddel (xsi:type = StatusRequest) Element Värde Beskrivning statuscodeid (enl. SXL) Statusförfrågans unika beteckning. Den exakta utformningen bestäms av signalutbyteslistan (SXL). Exemplen i denna handling är utformade enligt följande format: Syyy, där yyy är löpnummer. name (enl. SXL) Unik referens för värdet Struktur för meddelande med status på ett eller flera berörda objekt Ett meddelande med status på flera berörda objekt är utformat enligt nedan. Om objektet inte är känt så får anläggningen ej avbryta kommunikationsförbindelsen utan istället svara med detta typ av meddelade där agestate innehåller undefined. Fet text innebär variabelt innehåll vilket kan ändras beroende på lokala omständigheter. Övrig text är del av meddelandets grundstruktur. <roadsidemessage modelbaseversion="1.0" xmlns=" xsi:schemalocation=" RoadSideMessage_1_0_1_4.xsd"> <message xsi:type="statusresponse"> <messageid>{e68a0010-c336-41ac-bd58-5c80a72c7092}</messageid> <ntsobjectid>f+40100=416cg100</ntsobjectid> <externalntsid>23055</externalntsid> <componentid>ab+84001=860va001</componentid> <statustimestamp> t14:34:34.345z</statustimestamp> <returnvalues> <returnvalue> <statuscodeid>s003</statuscodeid> <name>speed</name> <status>70</status> <agestate>recent</agestate> </returnvalue> <returnvalue> <statuscodeid>s003</statuscodeid> <name>occupancy</name> <status>14</status> <agestate>recent</agestate> </returnvalue> </returnvalues>

24 RIKTLINJE 24 (55) XML-kod 7: Ett svar på statusförfrågan i syfte att informera om aktuellt värde på efterfrågat objekt. I detta exempel vilket budskap som visas på en skylt (70 km/h) Följande tabeller beskrivet tillåtet innehåll i meddelandet Huvuddel (xsi:type = StatusResponse) Element Värde Beskrivning statustimestamp (tidsstämpel) Tidsstämpling enligt W3C XML datetimedefinition med en noggrannhet på 3 decimaler. Tidsstämplingen sker i anläggning och gäller för då statusen hämtas. All tidsstämpling anges i UTC. description (skickas ej) (enl. SXL) Beskrivningstext för statusförfrågan. Definieras i SXL men skickas ej i meddelandet Eventuella returvärden (returnvalue) Element Värde Beskrivning statuscodeid (enl. SXL) Statusförfrågans unika beteckning. Den exakta utformningen bestäms av signalutbyteslistan (SXL). Exemplen i denna handling är utformade enligt följande format: Syyy, där yyy är löpnummer. name (enl. SXL) Unik referens för värdet type (skickas ej) (enl. SXL) Värdets datatyp. Exakt definition i SXL. Definieras i SXL men skickas ej i meddelandet Generell definition: string Textinformation integer Numeriskt värde (16-bits signed integer), [ ] long Numeriskt värde (32-bit signed long) real Flyttal (64-bit double precision floating point) boolean Boolesk datatyp (True/False) base64 Binär data uttryckt i base64-format enligt RFC-4648 unit (skickas ej) (enl. SXL) Värdets enhet. Definieras i SXL men skickas ej i meddelandet status (enl. SXL) Värde från utrustning agestate recent Medföljande värde är aktuellt old unknown undefined Medföljande värde är föråldrat ( gammalmärkt ) Medföljande värde är okänt och inga uppdateringar kommer att skickas. Objektet är okänt och inga uppdateringar kommer att skickas. I detta fall skall status vara satt till null.

25 RIKTLINJE 25 (55) Struktur för meddelande med förfrågan om prenumeration på status för ett eller flera objekt Ett meddelande med förfrågan om prenumeration på status är utformat enligt nedan. Meddelandet används för att bygga upp en prenumerationslista på status, ärvärden och händelser som man vill ha upp till överordnat system, t.ex. temperaturer, vindhastigheter, strömförbrukning, manuell styrning, gul blink. Fet text innebär variabelt innehåll vilket kan ändras beroende på lokala omständigheter. Övrig text är del av meddelandets grundstruktur. <roadsidemessage modelbaseversion="1.0" xmlns=" xsi:schemalocation=" RoadSideMessage_1_0_1_4.xsd"> <message xsi:type="statussubscribe"> <messageid>{e68a0010-c336-41ac-bd58-5c80a72c7092}</messageid> <ntsobjectid>f+40100=416cg100</ntsobjectid> <externalntsid>23055</externalntsid> <componentid>ab+84001=860va001</componentid> <statuses> <status> <statuscodeid>s003</statuscodeid> <name>speed</name> <updaterate>10</updaterate> </status> <status> <statuscodeid>s003</statuscodeid> <name>occupancy</name> <updaterate>10</updaterate> </status> </statuses> XML-kod 8: Ett meddelande med förfrågan om prenumeration på status för efterfrågade objekt Tillåtet innehåll redovisas nedan och i kapitel Huvuddel (xsi:type = StatusRequest) Element Värde Beskrivning updaterate (textfält) Anger hur ofta som meddelandet ska skickas. Definieras i sekunder, med ev. decimaler t.ex. 2.5 för 2,5 sekunder. Punkt (.) används som decimaltecken. Om 0 skickas så betyder det att värdet ska skickas vid förändring Struktur för meddelande med svar på förfrågan om prenumeration på status för ett eller flera objekt Ett meddelande med svar på förfrågan om prenumeration på status är utformat enligt nedan. Meddelandet skickas alltid direkt efter förfrågan på prenumeration oavsett om värdet nyligen ändrats eller p.g.a. intervall för prenumerationen. Detta eftersom man sannolikt påbörjar en prenumeration vid början av kommunikationsförbindelsen och därmed behöver uppdatera aktuell status på värden och händelser. Om en prenumeration på berörd status och objekt redan är aktiv så skall inte anläggningen etablera ytterligare prenumeration utan använda den befintliga. Meddelandet skall inte

26 RIKTLINJE 26 (55) skickas som svar vid prenumerationsförfrågan om prenumerationen redan är aktiv. Om objektet inte är känt så får anläggningen ej avbryta kommunikationsförbindelsen utan istället svara med detta typ av meddelade där agestate innehåller undefined Fet text innebär variabelt innehåll vilket kan ändras beroende på lokala omständigheter. Övrig text är del av meddelandets grundstruktur. <roadsidemessage modelbaseversion="1.0" xmlns=" xsi:schemalocation=" RoadSideMessage_1_0_1_4.xsd"> <message xsi:type="statusupdate"> <messageid>{e68a0010-c336-41ac-bd58-5c80a72c7092}</messageid> <ntsobjectid>f+40100=416cg100</ntsobjectid> <externalntsid>23055</externalntsid> <componentid>ab+84001=860va001</componentid> <statustimestamp> t14:34:34.345z</statustimestamp> <returnvalues> <returnvalue> <statuscodeid>s003</statuscodeid> <name>speed</name> <status>70</status> <agestate>recent</agestate> </returnvalue> <returnvalue> <statuscodeid>s003</statuscodeid> <name>occupancy</name> <status>14</status> <agestate>recent</agestate> </returnvalue> </returnvalues> XML-kod 9: Ett meddelande med svar på förfrågan om prenumeration på status för efterfrågade objekt Samtligt tillåtet innehåll redovisas i kapitel och Struktur för meddelande med förfrågan om avslutande av prenumeration på status för ett eller flera objekt Ett meddelande med svar på förfrågan prenumeration på status är utformat enligt nedan. Meddelandet tar bort prenumeration på ett eller flera objekt. På detta meddelande skickas inget särskilt svar, annat en meddelandekvittens. Fet text innebär variabelt innehåll vilket kan ändras beroende på lokala omständigheter. Övrig text är del av meddelandets grundstruktur. <roadsidemessage modelbaseversion="1.0" xmlns=" xsi:schemalocation=" RoadSideMessage_1_0_1_4.xsd"> <message xsi:type="statusunsubscribe"> <messageid>{e68a0010-c336-41ac-bd58-5c80a72c7092}</messageid>

27 RIKTLINJE 27 (55) <ntsobjectid>f+40100=416cg100</ntsobjectid> <externalntsid>23055</externalntsid> <componentid>ab+84001=860va001</componentid> <statuses> <status> <statuscodeid>s003</statuscodeid> <name>speed</name> </status> <status> <statuscodeid>s003</statuscodeid> <name>occupancy</name> </status> </statuses> XML-kod 10: Ett meddelande med förfrågan om avslutande av prenumeration på status för efterfrågade objekt Samtligt tillåtet innehåll redovisas i kapitel Meddelandeutbyte mellan anläggning och annan anläggning/överordnat system vid förfrågan Kvittering på att meddelanden mottagits (enl. kapitel 5.4.5) är implicit i nedanstående figurer. 1 Förfrågan om status på angivet objekt 2 Meddelande med status på angivet objekt Meddelandeutbyte mellan anläggning och annan anläggning/överordnat system vid prenumeration Kvittering på att meddelanden mottagits (enl. kapitel 5.4.5) är implicit i nedanstående figurer.

28 RIKTLINJE 28 (55) 1 Meddelande med status på angivet objekt STYRNINGS- OCH KOMMANDOMEDDELANDEN Styrningsmeddelande används för att ge order om att utföra något hos anläggning. Som kvittens så svarar anläggningen med motsvarande svar på styrningsmeddelande. Styrningsmeddelande är interaktionsstyrt och skickas när styrning efterfrågas på berört objekt av överordnat system eller annan anläggning Meddelandestruktur Struktur för styrningsmeddelande Ett styrningsmeddelande är utformat enligt nedan. Fet text innebär variabelt innehåll, t.ex. meddelandeinformation, status, identitet och tidpunkt. Övrig text är del av meddelandets grundstruktur. <roadsidemessage modelbaseversion="1.0" xmlns=" xsi:schemalocation=" RoadSideMessage_1_0_1_4.xsd"> <message xsi:type="commandrequest"> <messageid>{e68a0010-c336-41ac-bd58-5c80a72c7092}</messageid> <ntsobjectid>f+40100=416cg100</ntsobjectid> <externalntsid>23055</externalntsid> <componentid>ab+84001=860va001</componentid> <arguments> <argument> <commandcodeid>m002</commandcodeid> <name>1</name>

29 RIKTLINJE 29 (55) <command>setvalue</command> <value>auto</value> </argument> </arguments> XML-kod 11: Ett styrningsmeddelande i syfte att ändra aktuellt värde på efterfrågat objekt. Följande tabeller beskriver tillåtet innehåll i meddelandet Eventuella värden att skicka med styrkommando (argument) Element Värde Beskrivning commandcodeid (enl. SXL) Styrningsordens unika beteckning. Den exakta utformningen bestäms av signalutbyteslistan (SXL). Exemplen i denna handling är utformade enligt följande format: Myyy, där yyy är löpnummer. name (enl. SXL) Unik referens för värdet command (enl. SXL) Styrkommando type (skickas ej) (enl. SXL) Värdets datatyp. Definieras i SXL men skickas ej i meddelandet Generell definition: string Textinformation integer Numeriskt värde (16-bits signed integer), [ ] long Numeriskt värde (32-bit signed long) real Flyttal (64-bit double precision floating point) boolean Boolesk datatyp (True/False) base64 Binär data uttryckt i base64-format enligt RFC-4648 unit (skickas ej) (enl. SXL) Värdets enhet. Definieras i SXL men skickas ej i meddelandet value (enl. SXL) Värde Struktur för meddelande med svar på styrning Ett svar på styrningsmeddelande är utformat enligt nedan. Om objektet inte känt så får anläggningen ej avbryta kommunikationsförbindelsen utan istället svara med detta typ av meddelade där agestate innehåller undefined. Fet text innebär variabelt innehåll, t.ex. meddelandeinformation, status, identitet och tidpunkt. Övrig text är del av meddelandets grundstruktur. <roadsidemessage modelbaseversion="1.0" xmlns=" xsi:schemalocation=" RoadSideMessage_1_0_1_4.xsd"> <message xsi:type="commandresponse"> <messageid>{e68a0010-c336-41ac-bd58-5c80a72c7092}</messageid> <ntsobjectid>f+40100=416cg100</ntsobjectid> <externalntsid>23055</externalntsid> <componentid>ab+84001=860va001</componentid> <commandtimestamp> t14:34:34.345z</commandtimestamp>

30 RIKTLINJE 30 (55) <returnvalues> <returnvalue> <commandcodeid>m002</commandcodeid> <agestate>recent</agestate> <name>1</name> <value>auto</value> </returnvalue> </returnvalues> XML-kod 12: Ett svar på ett styrningsmeddelande i syfte att informera om uppdaterat värde på efterfrågat objekt. I detta fall har budskapet på en skylt ändrats till 70 Följande tabeller beskriver tillåtet innehåll i meddelandet Huvuddel (xsi:type = CommandResponse) Element Värde Beskrivning commandtimestamp (tidsstämpel) Tidsstämpling enligt W3C XML datetimedefinition med en noggrannhet på 3 decimaler. Tidsstämplingen sker i anläggning och gäller för då statusen hämtas. All tidsstämpling anges i UTC Eventuella returvärden (returnvalue) Element Värde Beskrivning commandcodeid (enl. SXL) Styrningsordens unika beteckning. Den exakta utformningen bestäms av signalutbyteslistan (SXL). Exemplen i denna handling är utformade enligt följande format: Myyy, där yyy är löpnummer. agestate recent Medföljande värde är aktuellt old Medföljande värde är föråldrat ( gammalmärkt ) unknown Medföljande värde är okänt och inga uppdateringar kommer att skickas. undefined Objektet är okänt och inga uppdateringar kommer att skickas. I detta fall skall value vara satt till null. name (enl. SXL) Unik referens för värdet type (skickas ej) (enl. SXL) Värdets datatyp. Definieras i SXL men skickas ej i meddelandet Generell definition: string Textinformation integer Numeriskt värde (16-bits signed integer), [ ] long Numeriskt värde (32-bit signed long) real Flyttal (64-bit double precision floating point) boolean Boolesk datatyp (True/False) base64 Binär data uttryckt i base64-format enligt RFC-4648 unit (skickas ej) (enl. SXL) Värdets enhet. Definieras i SXL men skickas ej i meddelandet value (enl. SXL) Värde från utrustning

31 RIKTLINJE 31 (55) Meddelandeutbyte mellan anläggning och annan anläggning/överordnat system Kvittering på att meddelanden mottagits (enl. kapitel 5.4.5) är implicit i nedanstående figurer. 1 Förfrågan om styrning skickas till anläggning 2 Anläggning svarar med svar på styrningsmeddelande för angivet objekt KVITTERING PÅ ATT MEDDELANDE MOTTAGITS Kvitteringsmeddelanden skickas som ett initialt svar på samtliga meddelanden. Dessa ska inte förväxlas med larmkvittering som har en annan funktion. Syftet med kvitteringsmeddelanden är att på protokollnivå kunna utesluta kommunikationsavbrott och att fungera som en bekräftelse på att meddelandet har nått mottagaren. Det finns två typer utav kvitteringsmeddelanden en typ som bekräftar att meddelandet har nått mottagaren och att denna har förstått budskapet och en annan typ som bekräftar att meddelandet har nått mottagaren men att denna ej har förstått budskapet. Kvittensmeddelande är interaktionsstyrt och skickas när godtyckligt meddelande tas emot från överordnat system eller annan anläggning, med undantag från andra kvittensmeddelanden Meddelandestruktur mottagare har förstått budskapet Ett kvittensmeddelande där mottagande part har förstått budskapet är utformat enligt nedan. Fet text innebär variabelt innehåll, t.ex. meddelandeinformation, status, identitet och tidpunkt. Övrig text är del av meddelandets grundstruktur. <roadsidemessage modelbaseversion="1.0" xmlns="

32 RIKTLINJE 32 (55) xsi:schemalocation=" RoadSideMessage_1_0_1_4.xsd"> <message xsi:type="messageack"> <originalmessageid>{e4fsd010-c336-41ac-bd58-5c80a72c7092}</originalmessageid> XML-kod 13: En meddelandekvittens i syfte för att försäkra att föregående meddelande har mottagits Följande tabell beskriver tillåtet innehåll i meddelandet Huvuddel (xsi:type = MessageAck) Element Värde Beskrivning originalmessageid (GUID) Meddelandeidentitet. Genereras som ett GUID (Globally unique identifier) i den utrustningen som skickade det ursprungliga meddelandet. Endast version 4 av Leach-Salz UUID används. Denna meddelandeidentititet används för att hänvisa till vilket meddelande som kvitteras Meddelandestruktur mottagare har ej förstått budskapet Ett kvittensmeddelande där mottagande part ej har förstått budskapet är utformat enligt nedan. Fet text innebär variabelt innehåll, t.ex. meddelandeinformation, status, identitet och tidpunkt. Övrig text är del av meddelandets grundstruktur. <roadsidemessage modelbaseversion="1.0" xmlns=" xsi:schemalocation=" RoadSideMessage_1_0_1_4.xsd"> <message xsi:type="messagenotack"> <originalmessageid>{e4fsd010-c336-41ac-bd58-5c80a72c7092}</originalmessageid> <reason>alarmcode: A054 does not exist</reason> XML-kod 14: En meddelandekvittens i syfte för att försäkra att föregående meddelande har mottagits, men att detta inte har förståtts utav mottagande part Följande tabell beskriver tillåtet innehåll i meddelandet Huvuddel (xsi:type = MessageNotAck) Element Värde Beskrivning originalmessageid (GUID) Meddelandeidentitet. Genereras som ett GUID (Globally unique identifier) i den utrustningen som skickade det ursprungliga meddelandet. Endast version 4 av Leach-Salz UUID används. Denna meddelandeidentitet används för att hänvisa till vilket meddelande som kvitteras. reason (valfritt) Felmeddelande där all relevant information framgår gällande det meddelande som ej förstods utav mottagande system.