Interface Design Description DVM Exchange 2.0

Interface Design Description DVM Exchange 2.0

IDD DVM Exchange 2.0

Page 1 of 29

Table of Contents 1 Changes............................................................................................................................ 3 2 Introduction...................................................................................................................... 3 2.1 Objective of this document............................................................................................................. 3 2.2 System overview.............................................................................................................................3 2.3 Document overview........................................................................................................................ 4 2.3.1 Purpose of this IDD................................................................................................................ 4 2.3.2 Reading guide........................................................................................................................ 4

3 Referenced Documents...................................................................................................4 3.1 References..................................................................................................................................... 4

4 Interface Design............................................................................................................... 4 4.1 General........................................................................................................................................... 4 4.2 Generic Response..........................................................................................................................6 4.3 heartbeat........................................................................................................................................ 7 4.4 getConfiguration............................................................................................................................. 7 4.5 configUpdate.................................................................................................................................. 9 4.6 statusUpdate................................................................................................................................ 10 4.7 getStatus.......................................................................................................................................11 4.8 ServiceRequests.......................................................................................................................... 13 4.8.1 deployService....................................................................................................................... 13 4.8.2 undeployService................................................................................................................... 14 4.9 DVM Exchange 1.0 compliancy................................................................................................... 15 4.9.1 Generic structure of requests............................................................................................... 15 4.9.2 Generic structure of responses............................................................................................ 15 4.9.3 trafficService......................................................................................................................... 16 4.9.4 informationService................................................................................................................ 16 4.9.5 reroutingService................................................................................................................... 17 4.9.6 removeService......................................................................................................................18 4.9.7 getStatus...............................................................................................................................18

5 Tables.............................................................................................................................. 20 5.1 Table of Requirements..................................................................................................................20 5.1.1 Beheer.................................................................................................................................. 20 5.1.2 NMS Client............................................................................................................................20 5.1.3 DVM Systeem / NMS Server................................................................................................ 21 5.1.4 Beveiliging............................................................................................................................ 22 5.1.5 Berichtspecificatie.................................................................................................................22 5.1.6 DVM service configuratie......................................................................................................23 5.1.7 DVM service status...............................................................................................................24 5.1.8 DVM-service inzet-commando............................................................................................. 25 5.1.9 DVM Wegkantsysteem configuratie..................................................................................... 26 5.1.10 DVM wegkantsysteem status............................................................................................. 27 5.1.11 DVM scenario configuratie..................................................................................................27 5.1.12 DVM scenario status.......................................................................................................... 28


Page 2 of 29

1 Changes Number

description

date drawn

signature

initials

0.1

Initial setup

12-06-2012

PMG

0.2

Review Comments

20-06-2012

PMG

0.3

First public Draft

26-06-2012

PMG

0.4

Changed Messages

26-06-2012

PMG

0.5

Review comments

26-06-2012

PMG

0.6

Review comments

28-06-2012

PMG

date

2 Introduction This document gives a description of the interface standard DVM-Exchange, to be applied in the communication between Traffic Control Systems (TCS) for road traffic. In recent years, there has been a growing interest in Network Management, which is Dynamic Traffic Management beyond the level of local, stand-alone systems. Network Management is in essence the coordination of all the local systems in a given area. This requires a Network Control System (NCS, special case of a TCS) with connections with all the local systems in that area, systems from a variety of different manufacturers, installed in different periods of the past, often owned by different management authorities. Moreover, an NCS has connections with neighboring NCS's, and with the parent NCS for the surrounding network. Needless to say that building all these interfaces is far from trivial. First of all, there should be a common interface definition for TCS's

2.1 Objective of this document This document details the specification of an open interface, suitable for the exchange of requests between TCS's. The level of detail is intended to be such that actual implementation in TCS's becomes possible.

2.2 System overview. Each system controls a part of the entire network [of roads]. In order to solve or act on problems inside the network, the support of neighboring systems could be required. Each NMS / DVM will have its own interface node, capable of parsing the DVM Exchange messages and interface those to the actual system. By doing so, each separate system will get a link to other systems. By using a SOAP v1.1/HTTP connection, the interconnection will be decoupled as XML is basically plain text. As SOAP is a so called 'disconnected protocol' there will be no persistent connection between nodes. Connections are made the moment a message must be transmitted. Each node must be capable of accepting connections and creating connections. This implies a dual-role as server and client. Instead of being a dedicated server or client, it is a shifting role, depending on the flow of messages. Because of this setup, the software has to be implemented as both and the responsibility of synchronization shifts client-side, instead of server-side. With this interconnection it is possible for a system to request measures on the partner systems to regulate traffic inside its own region. IDD DVM Exchange 2.0

Page 3 of 29

2.3 Document overview 2.3.1 Purpose of this IDD This document describes the format of the inter-system messages. With this document, it is possible to write the command-parsers and -handlers needed to create an inter-system interface.

2.3.2 Reading guide 1. Throughout this document, the terms “client” and “server” are used. Those terms do not describe the designated role of a node but indicate the “role” of the current node. Each node is equal and is capable of handling requests as well as doing requests. 2. The following typefaces are used to indicate different kind of texts. This is normal text This is a keyword This is example code

3. At chapter 6, a table is included with the requirements from the IRS. A cross-reference is made to see which messages cover which requirements. Also the requirements are meant with each message.

3 Referenced Documents 3.1 References Document

Description

Title

DVM services Interface requirement specificatie (IRS)

Revision

20 mei 2012, version 1.1

Title

DVM-Exchange for the Exchange of Requests and Information within Dynamic Traffic Management

Revision

20 April 2011, version 0.3

4 Interface Design 4.1 General All messages are SOAP v1.1/HTTP based and only handle the exchange of information between systems. Each message contains at least the following information: •

SourceId

•

DestinationId


Page 4 of 29

•

RequestId

•

MessageTimeStamp

•

MessageBody

HeaderField

Type

Explanation

SourceId

string

Unique Identifier of the Sender. This can be the MacAddress of the hardware, a SHA-1 key or a UUID. As long as the Id is known on both sides of the connection.

DestinationId

string

Unique Identifier of the Receiver. This can be the MacAddress of the hardware, a SHA-1 key or a UUID. As long as the Id is known on both sides of the connection.

RequestId

string

Request number of this message. It is unique in combination with the SenderId and the ReceiverId.

MessageType

string

The type of Message. (See table )

MessageTimeStamp Timestamp

Timestamp according to RFC 3339

MessageBody

The actual message. How it is handled, depends on the kind of message, given by MessageType.

string

Each message has the same header-structure. Depending on the MessageType, the MessageBody can be different. Specific parameters are defined in the MessageBody. MessageTypes

Explanation

controlRequest serviceRequest The header will look like the following : <soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/”> <soap:body> <SenderId> <MessageId> <MessageType> <MessageTimeStamp> <MessageBody> ...

Each request is directly answered with a reply to indicate the message was received. Instead of repeating the header in every example, we assume it to be present. The following paragraphs, only the message body is shown. Messages can be generalized into the following hierarchy :


Page 5 of 29

4.2 Generic Response Sequence

:

Description : For each message received as a server, a reply to that message is returned, indicating the state of the message, the reason of rejection ( if applicable ) and the RequestId the reply is referring to. Example

:

<requestId>... <status>... ...

Status can be one of the following : Status Explanation ACCEPTED REJECTED FAILURE References : IRS_DVM.011, IRS_DVM.018, IRS_DVM.041


Page 6 of 29

4.3 heartbeat service

: ping

Sequence

:

Description : Each node is responsible for checking the availability of its partner system, by sending a so called “heartbeat” on regular intervals. Each heartbeat message is responded to with a standard Response which will ensure the connection can be made. If the reply is not received, it is assumed the server is down or the connection in between has a problem. The frequency a heartbeat is send, is determined by the system and should be configurable. It would be nice to have several intervals if the connection is down. In case of an unreachable node, one could imagine to send less heartbeats, the longer a system is down. Normal heartbeat frequency should be restored after its first successful connection. As stated earlier, every node behaves like a server and a client so basically every node sends heartbeats and responds to heartbeats. By doing so we ensure that communication can go both ways. Immediately after starting up, the DVM-Exchange node is required to check the connection to its partners and after that on regular intervals. Message

:

Response

:

<requestid> <status>... ...

References : IRS_DVM.005, IRS_DVM.008, IRS_DVM.009, IRS_DVM.018, IRS_DVM.019

4.4 getConfiguration service

: getConfiguration


Page 7 of 29

Sequence

:

Description : A getConfiguration Request is meant to retrieve a list from the partner node regarding the availability of services on the partner node. Directly after starting up, the node is responsible to retrieve the configuration from its partner-node(s). It will reflect the current configuration of all services provided by the partner-node. Before any communication between nodes, a configuration request must be send and honored. When the request is sent, without any ObjectIds, the entire list is retrieved, describing services provided by the partner node. If one or more objectIds are provided, the configuration is requested of specific objects. Objects like services can have one or more children in which we have an interest. To this reason, a parameter is available, called “depth”. With this parameter, the level of recursiveness can be adjusted. If the level of depth exceeds the number of children, all levels are returned. The default value is zero ( '0' ) and will return only the configuration of the object itself. To reduce the size of the messages and cpu-load, the system can decide to send several responses to one configuration request. The threshold to this decision should be configurable. Default behavior is to update or add only to the cache, those objects mentioned in the message. !! Only these services are returned to which the requester has authorization. This is determined on the “SourceID” of the message by the provider of the services. !! Message

:

<depth>0 ... ... ...

Response

:

<parentId>... ... ... ... ... ... <description>... ... ... ... <parentId>...


Page 8 of 29

... ... ... ... ... <description>...

References : IRS_DVM.006, IRS_DVM.012, IRS_DVM.013, IRS_DVM.014, IRS_DVM.030, IRS_DVM.031, IRS_DVM.032, IRS_DVM.033, IRS_DVM.034, IRS_DVM.035, IRS_DVM.043, IRS_DVM.044, IRS_DVM.045, IRS_DVM.046, IRS_DVM.052, IRS_DVM.053, IRS_DVM.054

4.5 configUpdate service

: configUpdate

Sequence

:

Description : Every node requesting a configuration of its partner-node(s) is registered for updates if permissions allows. When a configuration, i.e. the availability of a service or hardware changes, it is the responsibility of the owner-node to inform its partner-node(s). It can do so by sending an update message.

Message

:

<parentId>... ... ... ... ... <description>... ... ... ... <parentId>... ... ... ...


Page 9 of 29

... <description>...

Response

: <empty>

References : IRS_DVM.016, IRS_DVM.017

4.6 statusUpdate service

: statusUpdate

Sequence

:

Description : Every node requesting a configuration of its partner-node(s) is also registered for statusUpdates . When a status of an object changes, it is the responsibility of the owner-node to inform its partner-node(s). It can do so by sending an update message. Depending on the type of object, the information in the message will differ.

Message

:

... ... <status> ... ... <usage> <usedBy>... ... <usedBy>... ... ... ... ... ... <status>... ...

The following fields are valid for a StatusUpdate


Page 10 of 29

Type

Field

Explanation

Generic objectId Location

Location Information as GPS, BPS, etc.

LocationType

“GPS”, “BPS”, “WGS84” etc.

Status

Online, Offline, Auto or InUse

InUse (Optional)

Tells which “service” or “solution” is using this object by its ID.

CurrentDisplay

Embedded picture. In this case, all displays can be treated the same.

DRIP

Parking Name Capacity Vacant InFlow OutFlow VRI, TDI CurrentProgram

Response

: <empty>


4.7 getStatus service

: getStatus

Sequence

:

Description : A getStatus Request is meant to retrieve the current status of objects from the partner node. Directly after starting up, the node is responsible to retrieve the configuration and the status from its partner-node(s). It will reflect the current status of all objects provided by the partner-node. Before any communication between nodes, a configuration request must be send and honored. When the request is sent, without any ObjectIds, the entire status is retrieved. If one or more objectIds are provided, the status is requested of specific objects. Objects like services can have one or more children in which we have an interest. To this reason, a parameter is available, called “depth”. With this parameter, the level of recursiveness can be adjusted. If the level of depth exceeds the number of children, all levels are returned. The default value is zero ( '0' ) and will return only the configuration of the object itself. To reduce the size of the messages and cpu-load, the system can decide to send IDD DVM Exchange 2.0

Page 11 of 29

several responses to one status request. The threshold to this decision should be configurable. Default behavior is to update or add only to the cache, those objects mentioned in the message. !! Only these services are returned to which the requester has authorization. This is determined on the “SourceID” of the message by the provider of the services. !! Message

:

<depth>0 ... ... ...

Response

:

... ... <status> ... ... <usage> <usedBy>... ... <usedBy>... ... ... ... ... ... ... ... ... <status> ... ... <usage> <usedBy>... ... <usedBy>... ... ... ... Type

Field

Explanation

Generic ObjectId


Location

Location Information as GPS, BPS etc.

LocationType

“GPS”, “BPS”, “WGS84” etc.

Status Code

Online, Offline, Auto or InUse

Page 12 of 29

Type

Field

Explanation

Status Reason UsedBy

The Id of the object, claiming this object. (Could be a list of ID's)

CurrentDisplay

Embedded Picture. In this case, all siaplays can be treated the same.

DRIP

Parking Name Capacity Vacant InFlow OutFlow VRI, TDI CurrentProgram

References : IRS_DVM.013, IRS_DVM.015, IRS_DVM.036, IRS_DVM.037, IRS_DVM.038, IRS_DVM.039, IRS_DVM.048, IRS_DVM.049, IRS_DVM.050

4.8 ServiceRequests 4.8.1 deployService service

: deployService

Sequence

:

Deployment

Re-Deployment

Description : Deployment of a service is somewhat complicated. We work under the assumption that between two owners of systems there is an agreement about which service number causes what effect. Each pre-configured service has a maximum lifespan (Time To Live or TTL for short) which will be part of the configuration. In case a service can run autonomously, the TTL can be '0' indicating it can run as long as its conditions are met. If for some reason it is impossible to cancel a deployment, the service will revert to its default state, after the TTL is reached. This to prevent a service running indefinitely. To keep a service running beyond its lifespan, it is required to resend a deployment request again, before the end of the TTL. The receiving node will reset the TTL timer to


Page 13 of 29

its maximum immediatedly. If a requested service is already deployed by someone else, a denial will be the response, together with the reason why it was denied. A re-deployment will not be performed. If a service is terminated for any reason, partner-nodes will be informed through a status message. Each service deployment entry can have a priority. This is not absolute, but merely a request to the providing node. If conditions or other services overrule this priority, the providing node will ignore this priority and the deployment request will be scheduled for execution if conditions are met. Feedback on the status will be given through a statusUpdate message. !! A deployment request is only honored if the requester is authorized for the requested service. !! NB! A deployment request could trigger an external authorization request, but it is not covered yet. Message

:

<serviceRequest service=”deployService”> <services> <service Id=”...” priority=”...”/> ... ... <service Id=”...” priority=”...”/>

Response

:

<services> <service> ... ... ...


4.8.2 undeployService service

: undeployService

Sequence

:

Description : To stop a running service, an “undeployService” message can be send to the partnernode running the service.

Message

:

<serviceRequest service=”undeployService”> <services> <serviceId>... ...


Page 14 of 29

<serviceId>...

Response

:

<services> <service> ... ... ... ... ... <service> ... ... ...


4.9 DVM Exchange 1.0 compliancy 4.9.1 Generic structure of requests All types of requests have the following fields: • the id of the client TNMS • the id of the server TNMS • the request id, unique within the name-space of the client TNMS. The pair of client id and request id form a unique identification of the request within the scope of the server. • the time stamp, according to the clock of the client TNMS. • the request type • the content part. This is dependent on the request type. There are two types of requests: • NetworkManagementRequest - to request a functional service. • ControlRequest - to manage the DVM Exchange protocol.

4.9.2 Generic structure of responses One response is issued for each received request. Responses express, amongst other thin gs, that the request was correctly received. Responses have the following fields: • the id of the server TNMS • the id of the client TNMS • the original request id • the time stamp, according to the clock of the server TNMS • response type • status • response message (optional) • the content part (optional) A response consists of a status and optional a response message or content. The status is either: • ACCEPTED – the request has been received in good order and is pending for execution IDD DVM Exchange 2.0

Page 15 of 29

•

REJECTED – the request has been received in good order but is rejected for the reason specified in the status message FAILURE – the request is broken, the reason is specified in the status message

•

When the status is not ACCEPTED the reply can have an optional explanation. When the status is ACCEPTED the reply can have an optional content field that depends on the response type.

4.9.3 trafficService service

: trafficService

Sequence

:

Description : A trafficService influences the traffic flow in one or more network elements. A trafficservice can handle, besides an absolute value like speed or flow, a relative value. This relative value can range from -100 to 100. Its interpretation is as follows : 0 – Lowest possible impact on the service request. 100 – Highest possible impact on the service request. By “impact” we mean: relative to the controlling argument (speed, flow or capacity). The receiving NMS is responsible for the extent to which this relative value is taken into account. The effect should always be within the allowed control range of each NMS. Parameters :

Message

:

Response

:

•

Controlling argument: speed, flow, capacity

•

absolute value

•

relative value: between -100% and 100%

•

optional list of vehicle type to inform

•

optional list of transport types to inform

<request clientID=”...” serverID=”...” requestID=”...” time=”...”> ... ...

References :

4.9.4 informationService service

: informationService

Sequence

:

Description : Inform the traveller about the network element he is traveling on or is approaching Message

:

<request clientID=”...” serverID=”...” requestID=”...” time=”...”>


Page 16 of 29

... ... ...
Response

:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <ns2:exchangeResponse xmlns:ns2="http://dvm_exchange.nl/"> accepted TrafficService with requestId [12345] accepted

References :

4.9.5 reroutingService service

: reroutingService

Sequence

:

Description : Inform the traveller about an alternative route. Message

:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <ns2:exchange xmlns:ns2="http://dvm_exchange.nl/"> <request clientID="nl.vialis.client" serverID="nl.vialis.server" requestID="12345" time="2012-03-20T14:58:53.196CET"> A10Re_S116In <priority>15 300 rerouting info

Response

:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <ns2:exchangeResponse xmlns:ns2="http://dvm_exchange.nl/"> accepted Rerouting service with requestId [12345] accepted

References :


Page 17 of 29

4.9.6 removeService service

: RemoveService

Sequence

:

Description : A client can remove a previously invoked service from the server by its request Id. Parameters: request id of a previously submitted network management service Message

:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <ns2:exchange xmlns:ns2="http://dvm_exchange.nl/"> <request clientID="nl.vialis.client" serverID="nl.vialis.server" requestID="d88da14b-4a45-44b5-ad2e-efdf3e065538" time="2012-0320T14:58:53.743CET"> 12345

Response

:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <ns2:exchangeResponse xmlns:ns2="http://dvm_exchange.nl/"> acceptedService with requestId [12345] removed

References :

4.9.7 getStatus Service

: getStatus

Sequence

:

Description : Returns the status of a previously invoked network management service request. Parameters : request id of a previously invoked network management service Additional response parameters: • Status: ◦ pending – the server has not yet executed the request or the server did not yet receive a response from a downstream system or device ◦ done – the request has been executed successfully, a result description is given in the status message ◦ failed – the request has not been executed, a reason is given in the status message ◦ unknown – the request could be in any state, a reason is given in the


Page 18 of 29

•

status message Status message (optional, in case status is failed or unknown)

Message

:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <ns2:exchange xmlns:ns2="http://dvm_exchange.nl/"> <request clientID="nl.vialis.client" serverID="nl.vialis.server" requestID="c4707a74-fc19-492f-a2a2-071ca413d165" time="2012-0320T14:58:53.743CET"> <statusControlRequest> 12345

Response

:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <ns2:exchange xmlns:ns2="http://dvm_exchange.nl/"> <request clientID="nl.vialis.client" serverID="nl.vialis.server" requestID="c4707a74-fc19-492f-a2a2-071ca413d165" time="2012-0320T14:58:53.743CET"> <statusControlRequest> 12345

References :


Page 19 of 29

5 Tables 5.1 Table of Requirements The original requirements are in Dutch. To prevent misinterpretations due to language subtleties, we quote the dutch description as well as explanations. RequirementNo.

Description

Interface

Remarks

5.1.1 Beheer IRS_DVM.001

De interface is uitbreidbaar met nieuwe eisen en nieuwe informatie elementen die kunnen voortkomen uit de noodzaak om nieuwe DVM systemen aan te sluiten of door ontwikkelingen in het domein van verkeersmanagement

Door het gebruik van SOAP zijn nieuwe functionaliteiten vrij eenvoudig toe te voegen. Voorwaarde is echter wel dat deze ook door de parser worden ondersteund.

IRS_DVM.002

De interface blijft downward compatible. Dit wil zeggen dat systemen met een oudere versie met systemen met een nieuwere versie kunnen blijven communiceren onder de voorwaarden van de oudere versie.

Volgens de regels van een interface, wordt de interface alleen maar uitgebreid met nieuwe functionaliteiten terwijl de oude functionaliteiten zijn gewaarborgd.

IRS_DVM.003

De interface mag worden toegepast in alle type DVM systemen die voor aansturing vanuit een regelscenario in aanmerking komen. De interface mag ook worden toegepast in andere toepassingen. Hiervoor wordt geen beheer georganiseerd.

Dit kan worden gewaarborgd door de interface onder de GPL uit te brengen, of te beleggen bij een beheersorganisatie met deze condities.

IRS_DVM.004

De interface is toe te passen zowel door overheidsinstanties als door private partijen.

Dit kan worden gewaarborgd door de interface onder de GPL uit te brengen, of te beleggen bij een beheersorganisatie met deze condities.

5.1.2 NMS Client IRS_DVM.005

NMS Client moet voortdurend proberen verbinding te maken met DVM systeem / NMS server totdat de verbinding tot stand is gekomen

IRS_DVM.006

Het initiatief van het starten van een sessie wordt genomen door de client. De client stuurt een aanmeld-bericht naar de server zodra de verbinding tot stand is gekomen. (Opm: De client meldt zich op een server aan met een autorisatieschema.)

Na opstarten is de “client” verantwoordelijk voor het ophalen van de configuratie data. Hiermee wordt een vorm van “aanmelden” gedaan en wordt een aanvrager geabonneerd op statusen configuratie updates van die services waar de aanvrager rechten voor heeft.

IRS_DVM.007

Het initiatief van het beëindigen van een sessie wordt

Er is geen sprake van


4.3 heartbeat

Page 20 of 29

RequirementNo.

Description

Interface

genomen door de client dat de dienst afneemt. De client beëindigd een sessie door een afmeldbericht te sturen.

Remarks een sessie. Er dient derhalve ook geen afmeldbericht gestuurd te worden.

IRS_DVM.008

Een client moet de verbinding met DVM systeem / 4.3 heartbeat NMS server in stand houden door deze opnieuw op te bouwen als de verbinding verloren gaat. Na het opnieuw tot stand komen van de verbinding controleert de client of er berichten zijn gemist. Als er berichten zijn gemist wordt alle informatie opnieuw aan de server gevraagd.

IRS_DVM.009

Als een client gedurende instelbare tijd geen berichten heeft ontvangen van een server, wordt een keep alive bericht aan de server gestuurd. Indien er, binnen een vast te stellen tijd, geen acknowledge van de server wordt ontvangen, dan wordt de sessie beëindigd en wordt automatisch een nieuwe sessie gestart. (Opm. In de client moet instelbaar zijn hoeveel pogingen tot herconnectie worden ondernomen.)

4.3 heartbeat

5.1.3 DVM Systeem / NMS Server IRS_DVM.010

Een server moet op een verbinding van NMS client wachten

IRS_DVM.011

Elk commando van de client wordt direct beantwoord met een client bericht met daarij een toelichting als een commando niet kan worden uitgevoerd.

IRS_DVM.012

Na aanmelding stuurt de server configuratieinformatie over alle DVM services en bijbehorende wegkantsystemen waarvoor de client rechten heeft.

Dit is omgedraaid. Bij opstarten “haalt” de client de configuratie op bij de “server” aangezien er geen sessie wordt gestart.

IRS_DVM.013

Zodra een configuratie bericht van een scenario, een service of een wegkantsysteem is verstuurd wordt ook gestart met het automatisch zenden van de statusinformatie van het object, startend met de laatste status van dat object. Ook als de configuratie van de overige elementen nog niet is verzonden.

Implementie van de software. Dit heeft niets met het protocol te maken.

IRS_DVM.014

Server moet als reactie op een configuratiecommando 4.5 configUpdate bericht van client een of meerdere configuratieberichten naar de client sturen.

IRS_DVM.015

Statusinformatie van een scenario, een service of een wegkantsysteem wordt pas verstuurd nadat de configuratie van een object is verstuurd.

IRS_DVM.016

Zodra een configuratie van een scenario, DVMservice of wegkantsysteem is ontvangen worden automatisch doorgevoerde configuratie wijzigingen door de server verzonden. Een server moet een configuratiebericht sturen naar de clients zodra de configuratie is gewijzigd.

4.5 configUpdate

IRS_DVM.017

DVM Systeem / NMS Server moet een statusbericht sturen naar clients zodra de status of data van een scenario, DVM Service of wegkantsysteem is gewijzigd.

4.6 statusUpdate

IRS_DVM.018

Een server moet als reactie op het alive-bericht van een client een reply-bericht naar de betreffende client sturen.

4.3 heartbeat 4.2 Generic

IRS_DVM.019

Als een server gedurende instelbare tijd geen berichten heeft ontvangen van een client, wordt ook

4.3 heartbeat


Dit is standaard gedrag van een server 4.2 Generic

Implementatie van de software. Binnen een protocol zit geen validatie.

Page 21 of 29

RequirementNo.

Description

Interface

Remarks

een alive-bericht door de server aan de client verstuurd. Indien er, binnen een vast te stellen tijd, geen reply-bericht volgt van de client dan wordt de sessie door de server afgesloten. IRS_DVM.020

Elke server moet zelf kunnen bepalen welke prioriteit aan de afhandeling van de service-aanvragen wordt toebedeeld.

IRS_DVM.021

De server moet in staat zijn om minimaal 10 clients te bedienen zonder performance verlies.

IRS_DVM.022

Als een sessie wordt beëindigd door een client met een afmeldbericht dan wordt de inzet van alle scenario's en services, die voor de betreffende client worden uitgevoerd, gestaakt. (Opm: Sommige services kunnen autonoom functioneren. De server moet eventueel regelen dat bij uitschakeling van een DVM-service de service terugvalt in zijn autonome toestand.

4.8.1 deployService

Implmentatie van de software. Protocol zegt hier niets over. 4.8 ServiceRequest

5.1.4 Beveiliging IRS_DVM.023

De communicatie tussen systemen vindt alleen plaats over beveiligde verbindingen of binnen beveiligde netwerken (vb. VPN Tunnels).

Implementatie van de infrastructuur. Dit gaat buiten het protocol om.

IRS_DVM.024

De uitwisseling van informatie is beveiligd met een signing mechanisme.

Implementatie van de infrastructuur. Dit gaat buiten het protocol om.

IRS_DVM.025

De toegang tot systemen is beveiligd met een autorisatiemechanisme. Autorisatie vindt plaats op sessie niveau.

Aangezien er geen sessie zijn, gaat die in twee stappen. Ten eerste authorisatie op de infrastructuur en ten tweede identificatie binnen het protocol.

5.1.5 Berichtspecificatie IRS_DVM.026

De interface is gebaseerd op XML

4.1 General

IRS_DVM.027

Berichten moeten de volgende gegevens bevatten : • Controlegegevens waarmee de integriteit van het bericht getest kan worden. • Controlegegevens waarmee kan worden gedetecteerd dat een bericht is gemist. • Een berichttype zodat het bericht herkend wordt door de ontvanger. • Timestamp op het moment van verzenden van het bericht.

4.1 General

IRS_DVM.028

Er wordt onderscheid gemaakt in de volgende client berichten : • Aanmeld bericht • Afmeld bericht • Alive bericht • Reply bericht • DVM-scenarioconfiguratie-commando • DVM-scenariostatus-commando • DVM-serviceconfiguratie-commando • DVM-servicestatus-commando • DVM-serviceinzet-commando • DVM-wegkantsysteemconfiguratiecommando • DVM-wegkantsysteemstatus-commando

4.2 Generic 4.4 getConfiguration 4.7 getStatus 4.8.1 deployService 4.8.2 undeployService


Aan- en afmeld berichten komen te vervallen.

Page 22 of 29

RequirementNo.

Description

Interface

IRS_DVM.029

Er wordt onderscheid gemaakt in de volgende serverberichten : • Autorisatie bericht • Alive bericht • Reply bericht • DVM-scenarioconfiguratie • DVM-scenariostatus • DVM-serviceconfiguratie • DVM-servicestatus • DVM-wegkantsysteemconfiguratie • DVM-wegkantsysteemstatus

4.2 Generic 4.4 getConfiguration 4.7 getStatus 4.8.1 deployService 4.8.2 undeployService

Remarks

5.1.6 DVM service configuratie IRS_DVM.030

Een DVM-serviceconfiguratie-commando wordt door de server beantwoord met een update van een of alle configuraties van de DVM service waarvoor de client rechten heeft. Opmerkingen : 1. In de server wordt geconfigureerd welke clients rechten hebben op welke DVMservices. 2. Als rechten op DVM-service configuratie wijzigen dan wordt een nieuw configuratiebericht voor de DVM service gestuurd. 3. Als rechten tijdsafhankelijk zijn dan wordt configuratie gewijzigd en aan het afnemende NMS gemeld. De volgende rechtenniveaus worden onderscheiden:

•

Raadpleger : Een client met deze rechten kan zich aanmelden en vervolgens configuratie en statusberichten ontvangen van de objecten waarvoor rechten zijn verkregen.

•

Inzetter : Een client met raadpleegrechten maar ook rechten voor het geven van inzetcommando's

•

Eigenaar : Een client met dezelfde rechten als de inzetter, maar ook nog gemandateerd eigenaar van de service zodat aanvragen van andere clients door deze client geautoriseerd moeten worden.

2. 4.5 configUpdate 3.

IRS_DVM.031

Het inhoudelijke deel van het DVMserviceconfiguratie-commando bevat de volgende informatie : • identificatie van de DVM-Service. Hier kan worden aangegeven of de configuratie van alle of van één specifieke DVM-service wordt opgevraagd. Voor een specifieke service wordt gebruik gemaakt van de identificatie zoals deze wordt ontvangen als de configuratie van alle services wordt opgevraagd. Voordat een specifieke serive wordt gevraagd moet er dus altijd eerst een algemene configuratievraag worden verstuurd. Opm: Een algemene configuratievraag mag niet te snel achter elkaar worden uitgevoerd. Dit moet instelbaar zijn.

IRS_DVM.032

Het inhoudelijke deel van het DVM-serviceconfiguratie 4.5 configUpdate bevat voor elke DVM-server de volgende informatie: • Identificatie van de DVM-Service.


1. Implementatie van de software. Dit ligt buiten de scope van het bericht.

4.4 getConfiguration

Page 23 of 29

RequirementNo.

Description

• • • •

•

•

• •

Interface

Remarks

Een voor de server unieke identificatie van de DVM-service. DVM-service-naam Naam van de DVM-Service in klare tekst. DVM-service-toelichting Tekstuele toelichting op de uitvoering van de DVM-service en het doel er van. Wegbeheerder Tekstuele aanduiding van de wegbeheerder die de DVM-service aanbiedt. Configuratiekenmerk Kenmerk waarmee wordt aangegeven of dit bericht een NIEUWe, een GEWIJZIGDe of een VERWIJDERDe configuratie betreft. Bij nieuwe- of verwijderde configuraties moet de identificatie van de DVM-service al bekend zijn. Als een configuratie opnieuw wordt aangevraagd wordt het label NIEUW gebruikt. DVM-service doel en verwacht effect Tekstuele beschrijving van het doel en het verwachte effect van de service. Deze tekst is bedoeld om de gebruikers aan NMS te faciliteren bij het kiezen van services op tactisch of operationeel niveau. Randvoorwaarden Tekstuele beschrijving van de randvoorwaarden die door de serviceverlener zelf worden bewaakt. Per randvoowaarde wordt bij voorkeur een type, locatie en grenswaarde gegeven. Als een DVM-service zelf geen randvoorwaarden bewaakt wordt dit hier ook aangegeven. Locatieaanduiding Tekstuele beschrijving van de geografische locatie waarop de service betrekking heeft. Wegkantsystemen Lijst met identificaties van wegkantsystemen die bij de uitvoering van de DVM-service betrokken zijn. Informatie over de DVM wegkantsysteemconfiguratie wordt geleverd door het DVMwegkantsysteem configuratie bericht.

IRS_DVM.033

Alle configuratieinformatie moet na aanmelden binnen 2 minuten verstrekt zijn aan de klant.

Implementatie van de software. Dit valt buiten de scope van het protocol.

IRS_DVM.034

De volgorde van de configuratie-informatie mag door de server worden bepaald, behalve dat eerst alle informatie over DVM-services wordt verstuurd en vervolgens van de onderliggende DVMwegkantsystemen.


IRS_DVM.035

De server is vrij om de configuratie van meerdere DVM-services tegelijk in een bericht te versturen. Dit moet per client configureerbaar zijn.


5.1.7 DVM service status IRS_DVM.036

Een DVM-servicestatus-commando wordt door de server beantwoord met een update van een of alle statussen van de DVM-services waarvoor de client geautoriseerd is. NB : Statussen worden automatisch verstuurd ( mits gautoriseerd ) nadat de configuratie is verstuurd en/of status / data van de DVM-service is gewijzigd.


4.6 statusUpdate

Page 24 of 29

RequirementNo.

Description

Interface

IRS_DVM.037

Het inhoudelijke deel van het DVM-servicestatus4.4 getConfiguration commando bevat de volgende informatie : • Indentificatie van de DVM-service Hiermee wordt aangegeven van welke specificieke service de status wordt opgevraagd. Hierbij wordt gebruik gemaakt van de identificatie zoals deze wordt ontvangen uit de configuratievragen. Ook kan hier worden aangeduid of de status van alle services tegelijk wordt opgevraagd.

IRS_DVM.038

Het inhoudelijke deel van de DVM-servicestatus bevat 4.6 statusUpdate de volgende informatie : • Identificatie van de DVM-service • Naam huidige inzetter / aanvrager Naam in tekst van de client die de service momenteel heeft ingezet. Leeg indien de service momenteel niet in gebruik is. • Activeringstoestand Bevat de toestanden “Deactiveren”, “actief” en “niet-actief” zoals aangegeven in het toestands diagram in het IRS, aangevuld met de toestand “Onbekend”. Deze wordt gebruikt als de status wordt opgevraagd van een specifieke DVM-service welke niet bestaat. • Technische beschikbaarheid Waarde die aangeeft of de service wel of niet beschikbaar is door het niet beschikbaar zijn van onderliggende wegkantsystemen. • Overschrijding randvoorwaarden Waarde die aangeeft of de eigen randvoorwaarden van de service wel of niet overschreden zijn. • Activeringstoestand toelichting Tekstuele toelichting op de huidige toestand , bijvoorbeeld bij het optreden van een uitvoeringsfout. • Toelichting overschrijding randvoorwaarde Een tekstuele toelichting waarin extra informatie wordt gegeven over het overschrijden van een of meerdere randvoorwaarden. Opm: In het diagram in het IRS zijn de toestanden van de DVM-service weergegeven, voortkomend uit de activeringstoestand, technische beschikbaarheid en de overschrijding van de randvoorwaarden.

IRS_DVM.039

De server is vrij om de status van meerdere DVMservices tegelijk in een bericht te versturen. Dit moet per client configureerbaar zijn.

Remarks


5.1.8 DVM-service inzet-commando IRS_DVM.040

Het inhoudelijke deel van het DVM-service inzetcommando bevat de volgende informatie : • Identificatie van de specifieke DVM-service Identificatie zoals aangegeven in de configuratiegegevens van de DVM-service • Commando Deze kent de volgende mogelijkheden. Inzetten van de DVM-service uitzetten van de DVM-service • Kracht De kracht waarmee de DVM-service wordt ingezet. Een waarde van 0 – 5 • Periode


4.8 ServiceRequest

In enkele regio's wordt een aanvraag van een DVM-service expliciet door een operator geaccordeerd. Het resultaat van deze accordering moet worden teruggegeven in het reply-bericht op het inzet-commando. Als de accordering positief is, wordt gestart met het toestanddiagram in

Page 25 of 29

RequirementNo.

Description

Interface

Tijdsduur dat de service moet worden ingezet. Kan niet gedefinieerd zijn. IRS_DVM.041

Een DVM-service inzet-commando krijgt een reply bericht om aan te geven of het commando wordt verwerkt. Als een service zich in een toestand bevind waarin geen inzetcommando geaccepteerd kan worden, dan wordt dit actief teruggemeld in het reply bericht.

IRS_DVM.042

Maximale tijdsduur tussen inzetcommando en eerste terugmelding van een toestandswijziging van die service is 15 seconden.

Remarks figuur 2 van het IRS.

4.2 Generic

Het autorisatiemechanisme (al dan niet door een operator) wordt in figuur 3 van het IRS uitgelegd. Hierin wordt onderscheid gemaakt in de situatie dat de server zelf de autorisatie verleend en de situatie dat de autorisatie is gedelegeerd naar een andere client. Implementatie van de software. Dit valt buiten de scope van het protocol.

5.1.9 DVM Wegkantsysteem configuratie IRS_DVM.043

Een DVM-wegkantsysteem configuratie-commando wordt door de server beantwoord met de configuratie van een specifieke of van alle wegkantsystemen die op de server zijn aangesloten.

IRS_DVM.044

Het inhoudelijke deel van het DVM-wegkantsysteem 4.4 getConfiguration configuratie-commando bevat de volgende informatie : • Identificatie van het wegkantsysteem Hier kan worden aangegeven of de configuratie van alle of van één specifiek wegkantsysteem wordt opgevraagd. Voor een specifiek systeem wordt gebruik gemaakt van de identificatie zoals deze wordt ontvangen als de configuratie van alle systemen wordt opgevraagd. Voordat een specifiek systeem wordt gevraagd moet er altijd een algemene configuratievraag worden verstuurd.

IRS_DVM.045

Het inhoudelijke deel van de DVM-wegkantsysteem 4.5 configUpdate configuratie bevat de volgende informatie : Per DVM-wegkantsysteem • Identificatie van het wegkantsysteem Een voor de server unieke identificatie van het wegkantsysteem • DVM-wegkantsysteem naam Naam van de DVM-wegkantsysteem in tekst • Configuratiekenmerk Kenmerk waarmee wordt aangegeven of dit bericht een NIEUWe, een GEWIJZIGDe of een VERWIJDERDe configuratie betreft. Bij nieuw of verwijderde configuratie moet de identificatie van het wegkantsysteem al bekend zijn. • Locatie Locatie van het wegkantsysteem volgens de locatiereferentiemethode • Type van het wegkantsysteem (In ieder geval : VRI, bermDRIP, TDI,


Dit is bedoeld om informatie te kunnen synchroniseren. Alleen de configuratie van wegkantsystemen die in een DVM-service zijn betrokken waar een client recht op heeft, worden verzonden.

Page 26 of 29

RequirementNo.

Description

Interface

Remarks

parkeerverwijsbord, matrixsignaalgever). IRS_DVM.046

De server is vrij om de configuratie van meerdere wegkantsystemen tegelijk in een bericht te versturen. Dit moet per client configureerbaar zijn.


IRS_DVM.047

De geografische locatie van een DVMwegkantsysteem moet aan een weg gekoppeld kunnen worden. Locatiereferentie moet kaartonafhankelijk zijn.

Standaardisatie van de methode voor locatiereferenties over regionale partners is nog in ontwikkeling.

5.1.10 IRS_DVM.048

DVM wegkantsysteem status Een DVM-wegkantsysteem status-commando wordt door de server beantwoord met de status van een of alle wegkantsystemen die op de server zijn aangesloten.

1.

2.

IRS_DVM.049

Het inhoudelijke deel van het DVM-wegkantsysteem 4.7 getStatus status-commando bevat de volgende informatie: • Identificatie van een specifieke wegkantsysteem Hiermee wordt aangegeven van welk specifiek systeem de status wordt opgevraagd. Hierbij wordt gebruik gemaakt van de identificatie zoals deze wordt ontvangen uit de configuratievragen. Ook hier kan worden aangeduid of de status van alle systemen tegelijk worden opgevraagd.

IRS_DVM.050

Het inhoudelijke deel van de DVM-wegkantsysteem status bevat de volgende informatie : • Identificatie van DVM-wegkantsystemen Een voor de server unieke identificatie van het wegkantsysteem • Actuele status Deze kent twee toestanden “Operationeel” en “Niet-Operationeel”. • Actuele stand (Driptekst, Actieve VRI-regeling)

IRS_DVM.051

De server is vrij om de configuratie van meerdere wegkantsystemen tegelijk in een bericht te versturen. Dit moet per client configureerbaar zijn.

5.1.11 IRS_DVM.052

Een status kan slechts worden teruggegeven als de client hier rechten voor heeft. Statussen worden automatisch verstuurd (mits geautoriseerd) nadat de configuratie is verstuurd en/of status / data van het wegkantsystee m is gewijzigd.

4.6 statusUpdate


DVM scenario configuratie Een DVM-scenario configuratie-commando wordt door de server bantwoord met de configuratie van één


Een scenario representeert een

Page 27 of 29

RequirementNo.

Description

Interface

specifieke, of van alle scenario's waar een client recht op heeft.

samengestelde set van DVM-services zoals op de server geconfigureerd binnen een scenario, informatie te kunnen synchroniseren. De naam scenario is dus niet helemaal correct.

IRS_DVM.053

Het inhoudelijke deel van het DVM-scenario configuratie-commando bevat de volgende informatie : • Identificatie van het scenario Hier kan worden aangegeven of de configuratie van alle of van één specifiek scenario wordt opgevraagd. Voor een specifiek scenario wordt gebruik gemaakt van de identificatie zoals deze wordt ontvangen als de configuratie van alle scenario's wordt opgevraagd. Voordat een specifiek scenario wordt gevraagd, moet er altijd eerst een algemene configuratievraag worden verstuurd.

IRS_DVM.054

Het inhoudelijke deel van de DVN scenario 4.5 configUpdate configuratie bevat de volgende informatie : • Identificatie van het scenario Een voor de server unieke identificatie van het scenario. • DVM-scenario naam Naam van het scenario op de server in tekst. • Configuratiekenmerk Kenmerk waarmee wordt aangegeven of dit bericht een NIEUWe, een GEWIJZIGDe of een VERWIJDERDe configuratie betreft. Bij nieuw of verwijderde configuratie moet de identificatie van het scenario al bekend zijn. • DVM-services Lijst van DVM-services waaruit het scenario is opgebouwd. Informatie over de DVMservices wordt geleverd door het DVMservice configuratie bericht.

IRS_DVM.055

De server is vrij om de configuratie van meerdere scenario's tegelijk in een bericht te versturen. Dit moet per client configureerbaar zijn.

5.1.12 IRS_DVM.056

Remarks

4.4 getConfiguration


DVM scenario status Een DVM-scenariostatus commando wordt door de server beantwoord met de status van een of van alle scenario's die op de server zijn geconfigureerd.

4.7 getStatus

Opm : een status kan slechts worden teruggegeven als de gebruiker hier rechten voor heeft. Statussen worden automatisch verstuurd (mist geautoriseerd) nadat configuratie is verstuurd en of status / data van het scenario is gewijzigd. IRS_DVM.057

Het inhoudelijke del van de DVM scenario statuscommando bevat de volgende informatie. Identificatie van een specifiek scenario.

4.6 statusUpdate

Hiermee wordt aangegeven van welk specifiek scenario de status wordt opgevraagd. Hierbij wordt gebruik gemaakt van de identificatie zoals deze wordt ontvangen uit de configuratievragen. Ook kan hier


Page 28 of 29

RequirementNo.

Description

Interface

Remarks

worden aangeduid of de status van alle scenario's tegelijk wordt opgevraagd. IRS_DVM.058

Het inhoudelijke deel van het DVM wegkantsysteem status bevat de volgende informatie : Per DVM-wegkantsysteem • identificatie van DVM-scenario. Een voor de server unieke identificatie van het scenario. • Actuele status ('Ingezet”, “Niet-Ingezet”) • Actuele stand (“Alle services actief”, “Services gedeeltelijk actief”, “Services niet actief” )

IRS_DVM.059

De server is vrij om de configuratie van meerdere scenario's tegelijk in een bericht te versturen. Dit moet per client configureerbaar zijn.


4.6 statusUpdate


Page 29 of 29

Interface Design Description DVM Exchange 2.0

Recommend Documents