Riktlinje RSMP_Kommunikationsprotokoll_vägsidesutrustning

Transcription

1 (52)
RIKTLINJE
Skapat av (Efternamn, Förnamn, org)
DokumentID
Ev. ärendenummer
Jonsson Lars, Tvinit
TDOK 2011:256
[Ärendenummer]
Fastställt av
Dokumentdatum
Version
[Fastställt av]
2012-02-29
3.1.2
Dokumenttitel
RSMP – Kommunikationsprotokoll vägsidesutrustning
1 Innehållsförteckning
1! INNEHÅLLSFÖRTECKNING ...................................................................... 1!
2! DEFINITIONER .......................................................................................... 3!
3! INLEDNING ............................................................................................... 5!
3.1! BAKGRUND .................................................................................................................... 5!
4! SYFTE ......................................................................................................... 6!
4.1! IDENTIFIERADE BEHOV .................................................................................................. 6!
5! TILLÄMPNING ........................................................................................... 7!
5.1! OMFATTNING ................................................................................................................. 7!
5.1.1!
Ansvar .................................................................................................................................. 7!
5.2! OBJEKTMODELL............................................................................................................. 7!
5.3! TRANSPORT AV DATA ...................................................................................................... 8!
5.3.1!
Etablering av kommunikation ............................................................................................8!
5.3.2!
Kommunikationsavbrott ....................................................................................................8!
5.3.3!
Transport mellan anläggning och överordnat system .....................................................8!
5.3.4!
Transport mellan anläggningar ........................................................................................8!
5.4! GRUNDSTRUKTUR .......................................................................................................... 9!
5.4.1!
Larmmeddelanden ............................................................................................................ 10!
5.4.2!
”Aggregerad status”-meddelanden .................................................................................. 17!
5.4.3!
Statusmeddelanden .......................................................................................................... 20!
5.4.4!
Styrnings- och kommandomeddelanden .........................................................................26!
5.4.5!
Kvittering på att meddelande mottagits ..........................................................................29!
5.4.6!
RSMP/SUL Version ........................................................................................................... 32!
5.4.7!
Watchdog ........................................................................................................................... 34!
5.5! TILLÄMPNING AV JSON ............................................................................................... 36!
5.5.1!
Motsvarighet av termer .................................................................................................... 36!
5.5.2!
Wrapping av paket ........................................................................................................... 37!
5.5.3!
Larmmeddelanden ........................................................................................................... 38!
5.5.4!
”Aggregerad status”-meddelande ................................................................................... 40!
5.5.5!
Statusmeddelanden ...........................................................................................................42!
5.5.6!
Styrnings- och kommandomeddelanden ......................................................................... 47!
5.5.7!
Kvittering på att meddelande mottagits ..........................................................................49!
5.5.8!
RSMP/SUL Version ...........................................................................................................50!
5.5.9!
Watchdog ........................................................................................................................... 51!
TDOK 2010:21_Mall Riktlinje v. 1.0
2 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
6! ÄNDRINGSLOGG...................................................................................... 52!
3 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
2 Definitioner
Begrepp
Betydelse
SUL
Signalutbyteslista
NTS
Nationellt TrafikledningsStöd. System för trafikledningscentral.
Ersätter CTS
TLC
Trafikledningscentral
Maximo
Trafikverkets stödsystem för drifthantering
ITS-anläggning
Lokal vägsidesutrustning. Innefattar både fältnivå och lokalnivå
Anläggning
Lokal vägsidesutrustning
Överordnat system
Objekt
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
Objekttyp
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)).
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
NTS-Objekt
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 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
NTS-Objekttyp
Komponent
Komponent-ID
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 2007:54
ISSN 1401-9612
XML
Komponent-ID är på format AA+BBCDD=EEEFFGGG.
eXtensible Markup Language
JSON
JavaScript Object Notation
TCP/IP
Transfer Control Protocol/Internet Protocol
W3C
World Wide Web Consortium
DATEX II
Europeisk standard för meddelandeutbyte mellan trafikala system.
(www.datex2.eu)
RSMP
Road Side Message Protocol
5 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
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 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
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 fem
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 (SUL). Denna lista utgör även gränssnittet mellan
överordnat system/andra anläggningar och en anläggning.
De fem 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
•
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 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
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.
5.1.1
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. XML-schema (.xsd) eller JSON-schema för protokollet tillhandahålls av
Trafikverket vid behov.
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 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
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.
5.3.1
ETABLERING AV KOMMUNIKATION
Vid etablering av kommunikation skickas meddelanden i följande turordning.
1.
2.
3.
4.
RSMP/SUL-version (enl. kapitel 5.4.6)
Watchdog (enl. kapitel 5.4.7)
Aggregerad status (enl. kapitel 5.4.2)
Samtliga aktiva och blockerade larm skickas (enl. kapitel 5.4.1)
Larm som ej skickas tolkas som icke-aktiva och icke-blockerade av överordnat system.
5. Eventuella kvarliggande meddelanden i utrustningens utgående kommunikationsbuffert
skickas
6. Eventuella prenumerationer på statusmeddelanden etableras; eftersom dessa automatiskt
upphör vid kommunikationsavbott
5.3.2
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.
Eventuella prenumerationer på statusmeddelanden upphör ifall kommunikationsavbrott inträffar.
Vid händelse av kommunikationsavbrott eller strömavbrott får utgående kommunikationsbuffert hos
utrustning ej tömmas, detta gäller dock ej watchdog-meddelanden.
Den interna kommunikationsbufferten hos utrustningen måste som minimum vara dimensionerad till
att kunna lagra 1000 meddelanden. Vid full kommunikationsbuffert ska FIFO-princip tillämpas.
5.3.3
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.
5.3.4
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.
9 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
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="http://roadsidemessage.vv.se/1_0_1_4"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4 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>
</message>
</roadSideMessage>
XML8kod&1:&Grundstruktur&för&ett&XML8meddelande.&I&detta&exempel&så&är&meddelandetypen&satt&som&larmmeddelande&&
Följande tabell beskriver tillåtet innehåll i meddelandet.
Element
messageId
Värde
(GUID)
ntsObjectId
(valbar)
(enl. SUL)
externalNtsId
(valbar)
(enl. SUL)
Beskrivning
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
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.
componentId
(enl. SUL)
Komponent-ID för det objekt vilket meddelandet relaterar
till.
10 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
5.4.1
LARMMEDDELANDEN
Ett larmmeddelande skickas till överordnat system när
•
Ett larm blir aktivt/inaktivt
•
Ett larm kvitteras
•
Blockering av larm aktiveras eller avaktiveras
Vid larmkvittering kvitteras inte en enskild larmhändelse utan samtliga larmhändelser för ett visst
objekt med en viss larmkod. Med andra ord; objektet äger statusen på huruvida den är kvitterad eller
ej. Detta förhållningssätt förenklar både vid implementering men även vid hantering – ifall 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.
5.4.1.1
5.4.1.1.1
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 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.
<?xml version="1.0" encoding="utf-8"?>
<alarmCodeId>A001</alarmCodeId>
<externalAlarmCodeId>Lampfel på lykta 1 (röd)</externalAlarmCodeId>
<externalNtsAlarmCodeId>3143</externalNtsAlarmCodeId>
<alarmSpecialisation xsi:type="Issue">
11 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
<acknowledgeState>notAcknowledged</acknowledgeState>
<alarmState>active</alarmState>
<suspendState>notSuspended</suspendState>
<timestamp>2009-10-01T11: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>
</message>
</roadSideMessage>
XML8kod&2:&Ett&larmmeddelande&som&indikerar&ett&lampfel&hos&anläggning&AB+84001=860VA001.&&
Följande tabeller beskriver tillåtet innehåll i meddelandet.
5.4.1.1.1.1
Huvuddel (xsi:type = Alarm)
Element
alarmCodeId
Värde
(enl. SUL)
externalAlarmCodeId
(valbar)
(tillverkarspecifik)
externalNtsAlarmCodeId
(valbar)
(enl. SUL)
Beskrivning
Larmsuffix som tillsammans med komponent-id
identifierar larmet i anläggningen. Den exakta
utformningen bestäms av signalutbyteslistan (SUL).
Exemplen i denna handling är utformade enligt
följande format: Ayyy, där yyy är löpnummer.
Tillverkarspecifik larmkod och larmbeskrivning.
Fabrikat, modell, larmkod och eventuell
larmbeskrivning
Larmkod för att identifiera larmtyp i
(Benämns i SL31 Alarm-Code)
5.4.1.1.1.2
Larmstatus
Element
acknowledegeState
alarmState
suspendState
timestamp
Värde
acknowledged
notAcknowledged
inactive
active
suspended
notSuspended
(tidsstämpel)
Beskrivning
larmet är kvitterat
larmet är ej kvitterat
larmet är inaktivt
larmet är aktivt
larm är blockerade
larm är ej blockerade
Tidsstämpel för antingen när larmet inträffar,
kvitteras eller blockeras. Se innehållet i
alarmSpecialisation för vilken tidsstämpel som
avses.
12 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
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.
category
T
D
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. SUL)
priority
[0-9]
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 SUL.
(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)
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.
5.4.1.1.1.3 Eventuella returvärden (returnvalue)
Element
name
type
(skickas ej)
Värde
(enl. SUL)
(enl. SUL)
Beskrivning
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
string
Textinformation
integer Numeriskt värde (16-bit signed integer),
[-32768 – 32767]
13 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
long
real
unit
(skickas ej)
value
5.4.1.1.2
(enl. SUL)
(enl. SUL)
Numeriskt värde (32-bit signed long)
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
Struktur för larmkvitteringsmeddelande
Ett larmkvitteringsmeddelande är utformat enligt nedan. Fet text innebär variabelt innehåll, t.ex.
grundstruktur.
<externalAlarmCodeId>Larmfel på lykta 1 (röd)</externalAlarmCodeId>
<alarmSpecialisation xsi:type="Acknowledge" />
</message>
</roadSideMessage>
XML8kod&3:&Ett&larmkvitteringsmeddelande&som&kvitterar&larm&
5.4.1.1.2.1 Huvuddel (xsi:type = Alarm)
Element
Värde
Beskrivning
alarmCodeId
(enl. SUL)
externalAlarmCodeId
(valbar)
(valbar)
(enl. SUL)
larmbeskrivning
14 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
5.4.1.1.2.2
Larmkvittering (xsi:type = Acknowledge)
(inget innehåll)
5.4.1.1.3
Struktur för larmblockeringsmeddelande
Ett larmblockeringsmeddelande är utformat enligt nedan. Fet text innebär variabelt innehåll, t.ex.
grundstruktur.
<alarmSpecialisation xsi:type="Suspend">
<suspendAction>suspend</suspendAction>
</message>
</roadSideMessage>
XML8kod&4:&Ett&larmblockeringsmeddelande&i&syfte&att&blockera&larm&för&utrustning&
5.4.1.1.3.1
Huvuddel (xsi:type = Alarm)
Element
Värde
Beskrivning
alarmCodeId
(enl. SUL)
externalAlarmCodeId
(valbar)
(valbar)
(enl. SUL)
larmbeskrivning
15 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
5.4.1.1.3.2
Larmblockering (xsi:type = Suspend)
Element
suspendAction
5.4.1.2
Värde
suspend
resume
Beskrivning
Aktivera blockering av larm
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.
5.4.1.2.1
1
5.4.1.2.2
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)
16 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
5.4.1.2.3
1
5.4.1.2.4
Ett larm kvitteras från anläggning
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)
5.4.1.2.5
Ett larm blockeras/avblockeras från anläggning
17 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
1
5.4.2
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 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.
5.4.2.1
Meddelandestruktur
Ett "aggregerad status"-meddelande är utformat enligt nedan. Fet text innebär variabelt innehåll, t.ex.
grundstruktur.
<message xsi:type="AggregatedStatus">
<componentId>F+40100=416CG100</componentId>
<aggstatusTimeStamp>2009-10-02T14: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>
<state>
18 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
<name>3</name>
<state>true</state>
</state>
<state>
<name>4</name>
</state>
<state>
<name>5</name>
</state>
<state>
<name>6</name>
</state>
<state>
<name>7</name>
</state>
<state>
<name>8</name>
</state>
</aggregatedStatusSpecialisation>
</message>
</roadSideMessage>
XML8kod&5:&Ett&”aggregerad&status”8meddelande&i&syfte&att&informera&om&att&anläggning&har&bytt&funktionsläge,&
funktionsstatus&och/eller&driftstatus&
5.4.2.1.1
Huvuddel (aggregatedStatus)
Element
aggstatusTimeStamp
5.4.2.1.2
Värde
(tidsstämpel)
Beskrivning
statusen hämtas. All tidsstämpling anges i UTC.
Aggregerad status (aggregatedStatusSpecialisation)
Element
functionalPosition
Värde
(enl. SUL)
Beskrivning
Funktionsläge
functionalState
(valbar)
(enl. SUL)
Funktionsstatus
state
(se nedan)
Driftstatus (se nedan)
5.4.2.1.3
Driftstatus (state)
19 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
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
state
name
Värde
true|false
[1-8]
Beskrivning
Driftstatus (State Bit)
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 (SUL). Generell beskrivning av varje enskild bit redovisas i följande tabell
Element
state
Bit
(name)
1
2
3
4
5
6
7
8
5.4.2.2
Beskrivning
Status i överordnat
Anläggningen tagit ur drift av lokalt
styrsystem eller underhållspersonal är ute
vid objektet.
Överordnat system har ingen kontakt med
anläggningen
Anläggningen har ett larm som kräver
omedelbar åtgärd. (Prioritet 1)
Anläggningen har ett larm som inte kräver
omedelbar åtgärd, men som planeras in
under nästföljande arbetspass.
(Prioritet 2)
Anläggningen har ett larm som kommer att
åtgärdas vid nästa planerade
underhållsinsats. (Prioritet 3)
Anläggningen är anslutet och används för
närvarande.
Anläggningen är anslutet men används inte
för stunden
Anläggningen är inte anslutet till
överordnat system.
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 överordnat system
Kvittering på att meddelanden mottagits (enl. kapitel 5.4.5) är implicit i nedanstående figur.
20 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
(Driftstatus, funktionsstatus eller funktionsläge ändrar sig i anläggning)
1
5.4.3
Ett "Aggregerad status"-meddelande skickas till överordnat system
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
5.4.3.1
5.4.3.1.1
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.
<message xsi:type="StatusRequest">
<statuses>
<status>
<statusCodeId>S003</statusCodeId>
<name>speed</name>
</status>
21 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
<status>
<name>occupancy</name>
</status>
</statuses>
</message>
</roadSideMessage>
XML8kod&6:&En&statusförfrågan&i&syfte&att&begära&aktuellt&värde&på&efterfrågat&objekt&&
5.4.3.1.1.1
Huvuddel (xsi:type = StatusRequest)
Element
statusCodeId
Värde
(enl. SUL)
name
(enl. SUL)
5.4.3.1.2
Beskrivning
Statusförfrågans unika beteckning. Den exakta
följande format: Syyy, där yyy är löpnummer.
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. Fet text innebär variabelt
innehåll vilket kan ändras beroende på lokala omständigheter. Övrig text är del av meddelandets
grundstruktur.
<message xsi:type="StatusResponse">
<statusTimeStamp>2009-10-02T14:34:34.345Z</statusTimeStamp>
<returnvalues>
<returnvalue>
<name>speed</name>
<status>70</status>
<ageState>recent</ageState>
</returnvalue>
<returnvalue>
<status>14</status>
</returnvalue>
</returnvalues>
</message>
</roadSideMessage>
22 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
XML8kod&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.
5.4.3.1.2.1
Huvuddel (xsi:type = StatusResponse)
Element
statusTimeStamp
Värde
(tidsstämpel)
Beskrivning
description
(skickas ej)
(enl. SUL)
Beskrivningstext för statusförfrågan. Definieras i
SUL men skickas ej i meddelandet
5.4.3.1.2.2
Eventuella returvärden (returnvalue)
Element
statusCodeId
Värde
(enl. SUL)
name
type
(skickas ej)
(enl. SUL)
(enl. SUL)
Beskrivning
Statusförfrågans unika beteckning. Den exakta
följande format: Syyy, där yyy är löpnummer.
Värdets datatyp. Exakt definition i SUL. Definieras i
SUL men skickas ej i meddelandet
unit
(skickas ej)
status
(enl. SUL)
(enl. SUL)
raw
scale
unit
string
Textinformation
integer Numeriskt värde (16-bits signed integer),
[-32768 – 32767]
long
real
point)
nummerordning
enligt RFC-4648
meddelandet
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.
23 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
5.4.3.1.3
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.
<message xsi:type="StatusSubscribe">
<statuses>
<status>
<name>speed</name>
<updateRate>10</updateRate>
</status>
<status>
</status>
</statuses>
</message>
</roadSideMessage>
XML8kod&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 5.4.3.1.1.1.
5.4.3.1.3.1
Huvuddel (xsi:type = StatusRequest)
Element
updateRate
5.4.3.1.4
Värde
(textfält)
Beskrivning
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 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. Fet text innebär variabelt innehåll vilket kan ändras beroende på lokala
omständigheter. Övrig text är del av meddelandets grundstruktur.
24 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
<message xsi:type="StatusUpdate">
<returnvalues>
<returnvalue>
<name>speed</name>
<status>70</status>
</returnvalue>
<returnvalue>
<status>14</status>
</returnvalue>
</returnvalues>
</message>
</roadSideMessage>
XML8kod&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 5.4.3.1.2.1 och 5.4.3.1.2.2.
5.4.3.1.5
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.
<message xsi:type="StatusUnSubscribe">
<statuses>
25 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
<status>
<name>speed</name>
</status>
<status>
</status>
</statuses>
</message>
</roadSideMessage>
XML8kod&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 5.4.3.1.1.1.
5.4.3.2
Meddelandeutbyte mellan anläggning och annan anläggning/överordnat system – vid
förfrågan
1
2
5.4.3.3
Förfrågan om status på angivet objekt
Meddelande med status på angivet objekt
Meddelandeutbyte mellan anläggning och annan anläggning/överordnat system – vid
prenumeration
26 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
1
5.4.4
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.
5.4.4.1
5.4.4.1.1
Meddelandestruktur
Struktur för styrningsmeddelande
Ett styrningsmeddelande är utformat enligt nedan. Fet text innebär variabelt innehåll, t.ex.
grundstruktur.
<message xsi:type="CommandRequest">
<arguments>
<argument>
<commandCodeId>M002</commandCodeId>
<name>1</name>
<command>setValue</command>
27 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
<value>Auto</value>
</argument>
</arguments>
</message>
</roadSideMessage>
XML8kod&11:&Ett&styrningsmeddelande&i&syfte&att&ändra&aktuellt&värde&på&efterfrågat&objekt.&
5.4.4.1.1.1
Eventuella värden att skicka med styrkommando (argument)
Element
commandCodeId
Värde
(enl. SUL)
name
command
type
(skickas ej)
(enl. SUL)
(enl. SUL)
(enl. SUL)
unit
(skickas ej)
value
5.4.4.1.2
(enl. SUL)
(enl. SUL)
Beskrivning
Styrningsordens unika beteckning. Den exakta
följande format: Myyy, där yyy är löpnummer.
Styrkommando
meddelandet
raw
scale
unit
string
Textinformation
[-32768 – 32767]
long
real
point)
nummerordning
enligt RFC-4648
meddelandet
Värde
Struktur för meddelande med svar på styrning
Ett svar på styrningsmeddelande är utformat enligt nedan. Fet text innebär variabelt innehåll, t.ex.
grundstruktur.
<message xsi:type="CommandResponse">
28 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
<commandTimeStamp>2009-10-02T14:34:34.345Z</commandTimeStamp>
<returnvalues>
<returnvalue>
<name>1</name>
<value>Auto</value>
</returnvalue>
</returnvalues>
</message>
</roadSideMessage>
XML8kod&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”&
5.4.4.1.2.1
Huvuddel (xsi:type = CommandResponse)
Element
commandTimeStamp
5.4.4.1.2.2
Värde
(tidsstämpel)
Beskrivning
Eventuella returvärden (returnvalue)
Element
commandCodeId
Värde
(enl. SUL)
ageState
recent
old
unknown
name
type
(skickas ej)
(enl. SUL)
(enl. SUL)
Beskrivning
Styrningsordens unika beteckning. Den exakta
följande format: Myyy, där yyy är löpnummer.
Medföljande värde är aktuellt
Medföljande värde är föråldrat (”gammalmärkt”)
Medföljande värde är okänt och inga uppdateringar
kommer att skickas.
meddelandet
raw
scale
unit
string
Textinformation
[-32768 – 32767]
long
real
point)
nummerordning
29 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
base64
unit
(skickas ej)
value
5.4.4.2
(enl. SUL)
(enl. SUL)
Binär data uttryckt i base64-format
enligt RFC-4648
meddelandet
Meddelandeutbyte mellan anläggning och annan anläggning/överordnat system
1
2
5.4.5
Förfrågan om styrning skickas till anläggning
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.
5.4.5.1
Meddelandestruktur – mottagare har förstått budskapet
30 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
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.
<message xsi:type="MessageAck">
<originalMessageId>{E4FSD010-C336-41ac-BD58-5C80A72C7092}</originalMessageId>
</message>
</roadSideMessage>
XML8kod&13:&En&meddelandekvittens&i&syfte&för&att&försäkra&att&föregående&meddelande&har&mottagits&
5.4.5.1.1
Huvuddel (xsi:type = MessageAck)
Element
originalMessageId
5.4.5.2
Värde
(GUID)
Beskrivning
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.
<message xsi:type="MessageNotAck">
<originalMessageId>{E4FSD010-C336-41ac-BD58-5C80A72C7092}</originalMessageId>
<reason>alarmCode: A054 does not exist</reason>
</message>
</roadSideMessage>
XML8kod&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&
5.4.5.2.1
Huvuddel (xsi:type = MessageNotAck)
Element
originalMessageId
Värde
(GUID)
Beskrivning
Meddelandeidentitet. Genereras som ett GUID
(Globally unique identifier) i den utrustningen som
skickade det ursprungliga meddelandet. Endast
31 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
reason
5.4.5.3
5.4.5.3.1
1
2
5.4.5.3.2
1
2
(valfritt)
version 4 av Leach-Salz UUID används. Denna
meddelandeidentititet används för att hänvisa till
vilket meddelande som kvitteras.
Felmeddelande där all relevant information framgår
gällande det meddelande som ej förstods utav
mottagande system.
Meddelandeutbyte mellan anläggning, annan anläggning och överordnat system
Överordnat system skickar initialt meddelande
Godtyckligt meddelande skickas från överordnat system eller annan anläggning
Anläggning svarar med ett kvittensmeddelande.
Anläggning skickar initialt meddelande
Godtyckligt meddelande skickas från anläggning
Överordnat system eller annan anläggning svarar med ett kvittensmeddelande.
32 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
5.4.6
RSMP/SUL VERSION
Version av RSMP samt revision av SUL skickas alltid direkt efter etablering av kommunikation. Båda
kommunicerande parter skickar detta som första meddelande och inväntar därefter
meddelandekvittering innan någon annan kommunikation påbörjas. Samtliga RSMP-versioner som
stöds ska skickas med i meddelandet. Detta meddelande ska även kunna kompletteras i framtiden med
fler taggar/variabler (t.ex. datum) utav att det påverkar befintliga implementationer.
Om någon av parterna är obekväm med versionerna så meddelas detta via meddelandekvittering
(MessageNotAck) till den andra parten; därefter avslutas kommunikationen och ett larm genereras
internt hos båda parter. Ifall båda parterna har stöd för flera RSMP-versioner som båda stödjer ska
alltid den senaste versionen användas per automatik.
5.4.6.1
Meddelandestruktur
Ett versions-meddelande är utformat enligt nedan. I nedanstående exempel har den avsändande
partnern stöd för RSMP version 1.0, 1.2 samt 1.3 och använder SUL version 1.3. Fet text innebär
variabelt innehåll, t.ex. meddelandeinformation, status, identitet och tidpunkt. Övrig text är del av
meddelandets grundstruktur.
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4/RoadSideMessage_1_0_1_4.xsd">
<message xsi:type="Version">
<siteIds>
<siteId>F+40100=416</siteId>
</siteIds>
<rsmpVersions>
<rsmpVersion>1.0</rsmpVersion>
</rsmpVersions>
<sxlVersion>1.3</sxlVersion>
</message>
</roadSideMessage>
XML8kod&15:&Ett&versionsmeddelande&i&syfte&för&att&informera&vilka&version&av&RSMP&som&stöds&och&revision&av&SUL&som&
används&
5.4.6.1.1
Element
siteId
Huvuddel (xsi:type = Version)
Värde
(enl. SUL)
Beskrivning
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.
33 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
"
rsmpVersion
sxlRevision
5.4.6.2
(enl. riktlinje)
(enl. SUL)
”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.
Version av RSMP. T.ex. ”1.0”, ”1.1” eller ”1.3”
Revision av SUL. T.ex. ”1.3”
5.4.6.2.1
1
5.4.6.2.2
Anläggning skickar versions-meddelande
Versions-meddelande skickas från anläggning
Överordnat system/annan anläggning skickar versions-meddelade
34 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
1
5.4.7
Versions-meddelande skickas från överordnat system/annan anläggning
WATCHDOG
Det primära syftet med Watchdog-meddelanden är att säkerställa kommunikationsförbindelsen
mellan anläggning och överordnat system – dock ej till eventuella subsystem; till det används larm.
Det sekundära syftet med Watchdog-meddelanden är tillhandahålla tidstämpel som används för
regelbunden tidssynkronisering. Såtillvida inte särskilda skäl föreligger, så ska anläggning regelbundet
synkronisera sin klocka baserat på tidstämpling i Watchdog-meddelande från överordnat system –
dels vid etablering av kommunikation samt minst en gång per dygn.
Watchdog-meddelanden skickas i båda riktningar i varje kommunikationsförbindelse. Vid initial
etablering av kommunikationsförbindelse (efter RSMP-versionskontroll) ska watchdog-meddelanden
skickas.
5.4.7.1
Meddelandestruktur
Ett watchdog-meddelande är utformat enligt nedan. Fet text innebär variabelt innehåll, t.ex.
grundstruktur.
<message xsi:type="Watchdog">
<watchdogTimestamp>2009-10-02T14:34:34.341Z</watchdogTimestamp>
</message>
</roadSideMessage>
XML8kod&16:&Ett&watchdog8meddelande&i&syfte&för&att&försäkra&att&kommunikationen&fungerar&
5.4.7.1.1
Huvuddel (xsi:type = Watchdog)
Element
watchdogTimestamp
5.4.7.2
Värde
(tidsstämpel)
Beskrivning
watchdog-meddelandet skickas. All tidsstämpling
anges i UTC.
35 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
5.4.7.2.1
1
5.4.7.2.2
1
Anläggning skickar watchdog-meddelande
Watchdog-meddelande skickas från anläggning
Överordnat system/annan anläggning skickar watchdog-meddelande
Watchdog-meddelande skickas från överordnat system/annan anläggning
36 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
5.5
5.5.1
Tillämpning av JSON
MOTSVARIGHET AV TERMER
Följande tabell redovisar motsvarigheterna av de termer som används i XML-exemplen jämfört med
de termer som används i JSON-exemplen i denna handling. Observera att elementen formateras som
JSON string elements och inte som t.ex. JSON number eller boolean elements.
Element i XML
acknowledgeState
ageState (statusmeddelande)
ageState (styrningsmeddelande)
aggregatedStatusSpecialisation
aggstatusTimeStamp
alarmCodeId
alarmSpecialisation
alarmState
timestamp
arguments
category
command
commandCodeId
commandTimeStamp
componentId
externalAlarmCodeId
externalEventCodeId
externalNtsId
functionalPosition
functionalState
message xsi:type
messageId
name
originalMessageId
priority
reason
returnvalue
returnvalues (alarm)
returnvalues (statusresponse)
rsmpVersion
rsmpVersions
roadSideMessage
ntsObjectId
sideIds
siteId
source
state
status
statuses
Element i JSON
ack
age
q
aSS
aSTS
aCId
aSp
aS
ts
arg
cat
cO
cCI
cTS
cId
xACId
xECId
xNACId
xNId
fP
fS
type
mId
n
oMId
pri
rea
rv
rvs
sS
vers
RSMP
mType: rSMsg
ntsOId
siteId
sId
source
se
s
sS
37 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
statusCodeId
statusTimestamp
suspendState
sxlRevision
type
unit
updateRate
watchdogTimestamp
5.5.2
sCI
sTs
sS
SXL
t
u
uRt
wTs
WRAPPING AV PAKET
Både Json och XML paket kan vara knepiga att avkoda såtillvida man inte alltid vet när man har ett
komplett paket. Json saknar slut-tag och XML slut-tag kan förekomma i textmassan. För att kunna
känna av ett paketslut måste man göra en helt egen parser alternativt göra en del kod-tricks vilket inte
är särskilt bra.
I både Json och XML kan det förekomma tabbar (0x09), CR (0x0d) och LF (0x0a). Är paketen
serialiserade med .NET finns inte dessa specialtecken. Naturligt är därför användandet av ett formfeed
(0x0c), dvs ’\f’ i C/C++ samt C# världen. Formfeed förekommer inte i själva paketet eftersom det är
kodat i UTF-8 och koden behöver bara söka av inbufferten efter 0x0c och hantera varje paket ända tills
de inte förekommer fler.
Exempel:
{"mHdr":{"mType":"rSMsg","type":"Alarm","mId":"d2e9a9a1-a082-44f5-b4e0-6c9233 a204c","ts":"2009-1002T14:34:34.345Z"},"oId":{"sId":"AB+81102=881CG001","xNId
":"","cId":"AB+81102=881DG002"},"aOId":{"aCId":"A052","xACId":"052","xNACId":
"052","aSp":"Acknowledge"}}<0x0c>
JSON8kod&1:&Exempel&på&wrapping&av&paket&
Tecken inom <> är bytens binära innehåll i hex (ASCII koden), ex <0x0c> är ASCII kod 12, dvs FF
(formfeed).
38 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
5.5.3
5.5.3.1
LARMMEDDELANDEN
Struktur för larmmeddelande
Nedanstående exempel redovisar motsvarigheten av meddelandestruktur mellan XML och JSON.
Observera att vissa rader är radbrytna.
XML
JSON
{
<roadSideMessage modelBaseVersion="1.0"
"mType": "rSMsg",
xmlns="http://roadsidemessage.vv.se/1_0_1_4"
"type": "Alarm",
xsi:schemaLocation="http://roadsidemessage.vv.se/1_0_1_4
"mId": "E68A0010-C336-41ac-BD585C80A72C7092",
RoadSideMessage_1_0_1_4.xsd">
"ntsOId": "F+40100=416CG100",
"xNId": "23055",
"cId": "AB+84001=860VA001",
"aCId": "A001",
"xACId": "Lampfel på lykta 1 (röd)",
"xNACId": "3143",
"aSp": "Issue",
<externalAlarmCodeId>Lampfel på lykta 1 (röd)</externalAlarmCodeId>
"ack": "notAcknowledged",
"aS": "active",
<alarmSpecialisation xsi:type="Issue">
"sS": "notSuspended",
<acknowledgeState>notAcknowledged</acknowledgeState>
"aTs": "2009-10-01T11:59:31.571Z",
<alarmState>active</alarmState>
"cat": "D",
<suspendState>notSuspended</suspendState>
"pri": "2"
<timestamp>2009-10-01T11:59:31.571Z</timestamp>
"rvs": [
<category>D</category>
{
<priority>2</priority>
"n": "signalgrupp",
<returnvalues>
"v": "1"
<returnvalue>
},
<name>signalgrupp</name>
{
<value>1</value>
"n": färg",
</returnvalue>
<returnvalue>
<name>färg</name>
"v": "röd"
}]
}
<value>röd</value>
</returnvalue>
</returnvalues>
</message>
</roadSideMessage>
XML/JSON8kod&1:&Exempel&på&motsvarighet&av&larmmeddelande&XML/JSON&
39 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
5.5.3.2
Struktur för Larmkvitteringsmeddelande
XML
JSON
{
"mType": "rSMsg",
"type": "Alarm",
"mId": "E68A0010-C336-41ac-BD585C80A72C7092",
"ntsOId": "F+40100=416CG100",
"xNId": "23055",
<messageId>{E68A0010-C336-41ac-BD58-
"cId": "AB+84001=860VA001",
5C80A72C7092}</messageId>
"aCId": "A001",
"xACId": "Larmfel på lykta 1 (röd)",
"xNACId": "3143",
"aSp": "acknowledge",
"ack": "Acknowledged",
"aS": "active",
"sS": "notSuspended",
<alarmSpecialisation xsi:type="Acknowledge">
"aTs": "2009-10-01T11:59:31.571Z",
</message>
"cat": "b",
</roadSideMessage>
"pri": "2"
"rvs": [
{
"n": "signalgrupp",
"v": "1"
},
{
"n": färg",
"v": "röd"
}]
}
XML/JSON8kod&2:&Exempel&på&motsvarighet&av&larmkvitteringsmeddelande&XML/JSON&
40 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
5.5.3.3
Struktur för Larmblockeringsmeddelande
XML
JSON
{
"mType": "rSMsg",
"type": "Alarm",
"mId": "E68A0010-C336-41ac-BD585C80A72C7092",
"ntsOId": "F+40100=416CG100",
"xNId": "23055",
"cId": "AB+84001=860VA001",
"aCId": "A001",
"xACId": "Larmfel på lykta 1 (röd)",
"xNACId": "3143",
"aSp": "suspend"
}
<alarmSpecialisation xsi:type="Suspend">
<suspendAction>suspend</suspendAction>
</message>
</roadSideMessage>
XML/JSON8kod&3:&Exempel&på&motsvarighet&av&larmblockeringsmeddelande&XML/JSON&
5.5.4
5.5.4.1
”AGGREGERAD STATUS”-MEDDELANDE
Meddelandestruktur
41 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
XML
JSON
{
"mType": "rSMsg",
"type": "AggregatedStatus",
"mId": "E68A0010-C336-41ac-BD585C80A72C7092",
"ntsOId": "F+40100=416CG100",
<message xsi:type="AggregatedStatus">
"xNId": "23055",
"cId": "F+40100=416CG100",
"aSTS": "2009-10-02T14:34:34.345Z",
"fP": "Trafikstyrning",
"fS": "Automatiskt nedsatt hastighet",
<componentId>F+40100=416CG100</componentId>
<aggstatusTimeStamp>2009-1002T14:34:34.345Z</aggstatusTimeStamp>
"se": ["false", "true", "true", "false", "false", "false",
"false", "false"]
}
<aggregatedStatusSpecialisation>
<functionalPosition>Trafikstyrning</functionalPosition>
<functionalState>Automatiskt nedsatt hastighet</functionalState>
<state>
<name>1</name>
</state>
<state>
<name>2</name>
<state>true</state>
</state>
<state>
<name>3</name>
<state>true</state>
</state>
<state>
<name>4</name>
</state>
<state>
<name>5</name>
</state>
<state>
<name>6</name>
</state>
<state>
<name>7</name>
</state>
<state>
<name>8</name>
</state>
</aggregatedStatusSpecialisation>
42 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
</message>
</roadSideMessage>
XML/JSON8kod&4:&Exempel&på&motsvarighet&av&”aggregerad&status”8&meddelande&XML/JSON&
5.5.5
5.5.5.1
STATUSMEDDELANDEN
Struktur för meddelande med förfrågan om status för angivet objekt
XML
JSON
{
"mType": "rSMsg",
"type": "StatusRequest",
"mId": "E68A0010-C336-41ac-BD58-5C80A72C7092",
"ntsOId": "F+40100=416CG100",
"xNId": "23055",
<message xsi:type="StatusRequest">
"cId": "AB+84001=860VA001",
"sS":[
{"sCI": "S003"
”n":"speed"},
{"sCI": "S003",
"n":"occupancy"}
<statuses>
<status>
<name>speed</name>
</status>
<status>
</status>
</statuses>
]
}
</message>
</roadSideMessage>
XML/JSON8kod&5:&Exempel&på&motsvarighet&av&statusförfrågan&XML/JSON&
5.5.5.2
Struktur för meddelande med status för berört objekt
43 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
XML
JSON
{
"mType": "rSMsg",
"type": "StatusResponse",
"mId": "E68A0010-C336-41ac-BD58-5C80A72C7092",
"ntsOId": "F+40100=416CG100",
"xNId": "23055",
<message xsi:type="StatusResponse">
"cId": "AB+84001=860VA001",
"sTs": "2009-10-02T14:34:34.345Z",
"sS":[
{"sCI": "S003",
"n":"1",
"s": "70",
"q": "recent"},
<returnvalues>
{"sCI": "S007",
<returnvalue>
"n":"1",
"s": "0",
"q": "unknown"}
<name>1</name>
]
<status>70</status>
}
Text
</returnvalue>
<returnvalue>
<ageState>unknown</ageState>
<name>1</name>
<status>0</status>
</returnvalue>
</returnvalues>
</message>
</roadSideMessage>
XML/JSON8kod&6:&Exempel&på&motsvarighet&av&svar&på&statusförfrågan&XML/JSON&
5.5.5.3
Struktur för meddelande med förfrågan om prenumeration på status för ett eller flera
objekt
XML
JSON
{
"mType": "rSMsg",
"type": "StatusSubscribe"
"mId": "E68A0010-C336-41ac-BD58-5C80A72C7092”,
"ntsOId": "F+40100=416CG100",
"xNId": "23055",
<message xsi:type="StatusSubscribe">
"cId": "AB+84001=860VA001",
44 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
"sS":[
{"sCI": "S003",
"n": "speed",
"uRt": "10"},
{"sCI": "S003",
<statuses>
"n":" occupancy ",
<status>
"uRt": "10"}
<name>speed</name>
]
}
</status>
<status>
</status>
</statuses>
</message>
</roadSideMessage>
XML/JSON8kod&7:&Exempel&på&motsvarighet&av&förfrågan&om&prenumeration&XML/JSON&
45 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
5.5.5.4
Struktur för meddelande med svar på förfrågan om prenumeration på status för ett
eller flera objekt
XML
JSON
{
"mType": "rSMsg",
"type": "StatusUpdate",
"mId": "E68A0010-C336-41ac-BD58-5C80A72C7092",
"ntsOId": "F+40100=416CG100",
"xNId": "23055",
<message xsi:type="StatusUpdate">
"cId": "AB+84001=860VA001",
"sTs": "2009-10-02T14:34:34.345Z",
"sS":[
{"sCI": "S003",
"n":"1",
"s": "70",
"q": "recent"},
<returnvalues>
{"sCI": "S007",
<returnvalue>
"n":"1",
"s": "0",
"q": "unknown"}
<name>1</name>
<status>70</status>
]
}
</returnvalue>
<returnvalue>
<ageState>unknown</ageState>
<name>1</name>
<status>0</status>
</returnvalue>
</returnvalues>
</message>
</roadSideMessage>
XML/JSON8kod&8:&Exempel&på&motsvarighet&av&svar&på&förfrågan&om&prenumeration&XML/JSON&
5.5.5.5
Struktur för meddelande med förfrågan om avslutande av prenumeration på status för
ett eller flera objekt
46 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
XML
JSON
{
"mType": "rSMsg",
"type": "StatusUnsubscribe"
"mId": "E68A0010-C336-41ac-BD58-5C80A72C7092”,
"ntsOId": "F+40100=416CG100",
"xNId": "23055",
<message xsi:type="StatusUnSubscribe">
"cId": "AB+84001=860VA001",
"sS":[
{"sCI": "S003",
"n":"speed"},
{"sCI": "S003",
"n":" occupancy”}
<statuses>
<status>
]
}
<name>speed</name>
</status>
<status>
</status>
</statuses>
</message>
</roadSideMessage>
XML/JSON8kod&9:&Exempel&på&motsvarighet&av&svar&på&förfrågan&om&prenumeration&XML/JSON&
47 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
5.5.6
5.5.6.1
STYRNINGS- OCH KOMMANDOMEDDELANDEN
Struktur för styrningsmeddelande
XML
JSON
{
"mType": "rSMsg",
"type": "CommandRequest",
"mId": "E68A0010-C336-41ac-BD58-5C80A72C7092",
"ntsOId": "F+40100=416CG100",
"xNId": "23055",
<message xsi:type="CommandRequest">
"cId": "AB+84001=860VA001",
"arg": [
{
"cCI": "M003",
"n": "1",
"cO": "setValue",
<arguments>
"v": "Auto"
<argument>
}]
}
<name>1</name>
<command>setValue</command>
<value>Auto</value>
</argument>
</arguments>
</message>
</roadSideMessage>
XML/JSON8kod&10:&Exempel&på&motsvarighet&av&styrningsmeddelande&XML/JSON&
48 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
5.5.6.2
Struktur för meddelande med svar på styrning
XML
JSON
{
"mType": "rSMsg",
"type": "CommandResponse",
"mId": "E68A0010-C336-41ac-BD58-5C80A72C7092",
"ntsOId": "F+40100=416CG100",
"xNId": "23055",
<message xsi:type="CommandResponse">
"cId": "AB+84001=860VA001",
"cTS": "2009-10-02T14:34:34.345Z",
"rvs": [
{
"cCI": "M002",
"age": "recent",
<commandTimeStamp>2009-10-
"n": "1",
02T14:34:34.345Z</commandTimeStamp>
"v": "70"
<returnvalues>
<returnvalue>
}]
}
<name>1</name>
<value>Auto</value>
</returnvalue>
</returnvalues>
</message>
</roadSideMessage>
XML/JSON8kod&11:&Exempel&på&motsvarighet&av&svar&på&styrningsmeddelande&XML/JSON&
49 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
5.5.7
5.5.7.1
KVITTERING PÅ ATT MEDDELANDE MOTTAGITS
Meddelandestruktur - mottagare har förstått budskapet
XML
JSON
{
"mType": "rSMsg",
"type": "MessageAck",
"oMId": "F4FSD010-D587-7A3B-8BD5-5C80A72C7154"
}
<message xsi:type="MessageAck">
<originalMessageId>{E4FSD010-C336-41ac-BD585C80A72C7092}</originalMessageId>
</message>
</roadSideMessage>
XML/JSON8kod&12:&Exempel&på&motsvarighet&av&kvittering&där&mottagaren&har&förstått&budskapet&XML/JSON&
5.5.7.2
Meddelandestruktur - mottagare har ej förstått budskapet
XML
JSON
{
"mType": "rSMsg",
"type": "MessageNotAck",
"oMId": "F4FSD010-D587-7A3B-8BD5-5C80A72C7154",
"rea": "alarmCode: A054 does not exist"
}
<message xsi:type="MessageNotAck">
<originalMessageId>{E4FSD010-C336-41ac-BD585C80A72C7092}</originalMessageId>
<reason>alarmCode: A054 does not exist</reason>
</message>
</roadSideMessage>
XML/JSON8kod&13:&Exempel&på&motsvarighet&av&kvittering&där&mottagaren&ej&har&förstått&budskapet&XML/JSON&
50 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
5.5.8
5.5.8.1
RSMP/SUL VERSION
Meddelandestruktur
XML
JSON
{
"mType": "rSMsg",
"type": "Version",
<message xsi:type="Version">
"mId": "E68A0010-C336-41ac-BD585C80A72C7092",
"siteId":[
<siteIds>
{"sId":"F+40100=416CG100"}],
<siteId>F+40100=416CG100</siteId>
"RSMP":[
</siteIds>
{"vers":"1.0"},
<rsmpVersions>
{"vers":"1.2"},
{"vers":"1.3"}],
"SXL":"1.3"
}
</rsmpVersions>
<sxlVersion>1.3</sxlVersion>
</message>
</roadSideMessage>
XML/JSON8kod&14:&Exempel&på&versionsmeddelande&XML/JSON&
51 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
5.5.9
5.5.9.1
WATCHDOG
Meddelandestruktur
XML
JSON
{
"mType": "rSMsg",
"type": "Watchdog",
"mId": "E68A0010-C336-41ac-BD58-5C80A72C7092",
"wTs": "2009-10-02T14:34:34.345Z",
}
<message xsi:type="Watchdog">
<messageId>{E68A0010-C336-41ac-BD585C80A72C7092}</messageId>
<watchdogTimestamp>2009-1002T14:34:34.345Z</watchdogTimestamp>
</message>
</roadSideMessage>
XML/JSON8kod&16:&Exempel&på&motsvarighet&av&watchdog8meddelande&XML/JSON&
52 (52)
RIKTLINJE
DokumentID
Ev. ärendenummer
Version
TDOK 2011:256
[Ärendenummer]
3.1.2
6 Ändringslogg
Fastställd version
Dokumentdatum
Ändring
Namn
1.0
2011-05-20
DO
3.0
3.1.1
3.1.2
2011-11-04
2011-12-23
2012-02-29
Protokollet förtydligat
och watchdog reviderat
Protokollet reviderat
Mindre revidering
Mindre revidering
DO
DO
DO

Riktlinje RSMP_Kommunikationsprotokoll_vägsidesutrustning

Transcription

Similar documents

Dokumentsammanställning över aktuella dokument för

Artikel om LM Arte

Västra Bjäre Pianodagar 8 – 12 juli Västra Karups kyrka

Referensgrupp för projektet planerad nationalpark Åsnen:

Motesnoteringar_Intressegruppenmote_05

XMLguide - Vitec Hjälp Mäklarsystem

Regler för insamling och leverans av vägdata

XML-kontoraportering

BVF 922 - Elsäkerhetsföreskrifter för trafikplatser

Handbok Procapita Vård och Omsorg

Handbok Procapita Vård och Omsorg

Minnesanteckningar från kommunforum NVDB 2014-04-01