Interface Design Description DVM Exchange 2.0

Transcriptie

1 Interface Design Description DVM Exchange 2.0 IDD DVM Exchange 2.0 Page 1 of 29

2 Table of Contents 1 Changes. 3 2 Introduction Objective of this document System overview Document overview Purpose of this IDD Reading guide 4 3 Referenced Documents4 3.1 References. 4 4 Interface Design General Generic Response heartbeat getconfiguration configupdate statusupdate getstatus ServiceRequests deployservice undeployservice DVM Exchange 1.0 compliancy Generic structure of requests Generic structure of responses trafficservice informationservice reroutingservice removeservice getstatus.18 5 Tables Table of Requirements Beheer NMS Client DVM Systeem / NMS Server Beveiliging Berichtspecificatie DVM service configuratie DVM service status DVM-service inzet-commando DVM Wegkantsysteem configuratie DVM wegkantsysteem status DVM scenario configuratie DVM scenario status. 28 IDD DVM Exchange 2.0 Page 2 of 29

3 1 Changes Number description date drawn signature initials date 0.1 Initial setup PMG 0.2 Review Comments PMG 0.3 First public Draft PMG 0.4 Changed Messages PMG 0.5 Review comments PMG 0.6 Review comments PMG 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

4 2.3 Document overview 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 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 Revision 20 April 2011, version 0.3 DVM-Exchange for the Exchange of Requests and Information within Dynamic Traffic Management 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 IDD DVM Exchange 2.0 Page 4 of 29

5 RequestId MessageTimeStamp MessageBody HeaderField Type Explanation SourceId string Unique Identifier of the Sender. This can be the Mac- Address 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 Mac- Address 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 <ref> ) MessageTimeStamp Timestamp Timestamp according to RFC 3339 MessageBody string The actual message. How it is handled, depends on the kind of message, given by MessageType. Each message has the same header-structure. Depending on the MessageType, the MessageBody can be different. Specific parameters are defined in the MessageBody. MessageTypes controlrequest servicerequest Explanation The header will look like the following : <?xml version= 1.0 encoding UTF-8?> <soap:envelope xmlns:soap= > <soap:body> <SenderId></SenderId> <ReceiverId></ReceiverId> <MessageId></MessageId> <MessageType></MessageType> <MessageTimeStamp></MessageTimeStamp> <MessageBody> </MessageBody> </soap:body> </soap:envelope> 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 : IDD DVM Exchange 2.0 Page 5 of 29

6 4.2 Generic Response Sequence : Description Example : 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. : <response> <requestid></requestid> <status></status> <reason></reason> </response> Status can be one of the following : Status Explanation ACCEPTED REJECTED FAILURE References : IRS_DVM.011, IRS_DVM.018, IRS_DVM.041 IDD DVM Exchange 2.0 Page 6 of 29

7 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 : <controlrequest service= ping > </controlrequest> : <response> <requestid></requestid> <status></status> <reason></reason> </response> References : IRS_DVM.005, IRS_DVM.008, IRS_DVM.009, IRS_DVM.018, IRS_DVM getconfiguration service : getconfiguration IDD DVM Exchange 2.0 Page 7 of 29

8 Sequence : Description Message Response : 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.!! : <controlrequest service= getconfiguration > <depth>0</depth> <objects> <objectid></objectid> <objectid></objectid> </objects> </controlrequest> : <response requestid= > <objects> <objectid value= requestid= > <parentid></parentid> <children> <childid></childid> <childid></childid> </children> <lifespan></lifespan> <type></type> <description></description> <available></available> </objectid> <objectid value= requestid= > <parentid></parentid> <children> IDD DVM Exchange 2.0 Page 8 of 29

9 <childid></childid> <childid></childid> </children> <lifespan></lifespan> <type></type> <description></description> <available></available> </objectid> </objects> </response> 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 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 : <update type= configuration > <objects> <objectid value= > <parentid></parentid> <children> <childid></childid> <childid></childid> </children> <type></type> <description></description> <available></available> </objectid> <objectid value= requestid= > <parentid></parentid> <children> <childid></childid> <childid></childid> </children> IDD DVM Exchange 2.0 Page 9 of 29

10 Response <type></type> <description></description> <available></available> </objectid> <objects> </update> : <empty> References : IRS_DVM.016, IRS_DVM statusupdate service Sequence : : statusupdate 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 : <update type= status > <objects> <objectid value= type= > <location></location> <locationtype></locationtype> <status> <code></code> <reason></reason> </status> <usage> <usedby></usedby> <usedby></usedby> </usage> </objectid> <objectid value= type= > <location></location> <locationtype></locationtype> <status></status> <inuse></inuse> </objectid> </objects> </update> The following fields are valid for a StatusUpdate IDD DVM Exchange 2.0 Page 10 of 29

11 Type Field Explanation Generic DRIP Parking VRI, TDI objectid Location LocationType Status InUse (Optional) CurrentDisplay Name Capacity Vacant InFlow OutFlow CurrentProgram Location Information as GPS, BPS, etc. GPS, BPS, WGS84 etc. Online, Offline, Auto or InUse Tells which service or solution is using this object by its ID. Embedded picture. In this case, all displays can be treated the same. Response : <empty> References : IRS_DVM.016, IRS_DVM 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

12 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 Response : <controlrequest service= getstatus > <depth>0</depth> <objects> <objectid></objectid> <objectid></objectid> </objects> </controlrequest> : <response requestid= > <objects> <objectid value= type= > <location></location> <locationtype></locationtype> <status> <code></code> <reason></reason> </status> <usage> <usedby></usedby> <usedby></usedby> </usage> <objectinfo> <type></type> </objectinfo> </objectid> <objectid value= type= > <location></location> <locationtype></locationtype> <status> <code></code> <reason></reason> </status> <usage> <usedby></usedby> <usedby></usedby> </usage> <objectinfo> <type></type> </objectinfo> </objectid> </objects> </response> Generic Type Field Explanation ObjectId Location LocationType Status Code Location Information as GPS, BPS etc. GPS, BPS, WGS84 etc. Online, Offline, Auto or InUse IDD DVM Exchange 2.0 Page 12 of 29

13 DRIP Parking VRI, TDI Type Field Explanation Status Reason UsedBy CurrentDisplay Name Capacity Vacant InFlow OutFlow CurrentProgram The Id of the object, claiming this object. (Could be a list of ID's) Embedded Picture. In this case, all siaplays can be treated the same. 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 ServiceRequests 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 IDD DVM Exchange 2.0 Page 13 of 29

14 Message Response 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. : <servicerequest service= deployservice > <services> <service Id= priority= /> <service Id= priority= /> </services> </servicerequest> : <response requestid= > <services> <service> <Id></Id> <code></code> <reason></reason> </service> </services> </response> References : IRS_DVM.022, IRS_DVM undeployservice service Sequence : : undeployservice Description : To stop a running service, an undeployservice message can be send to the partnernode running the service. Message : <servicerequest service= undeployservice > <services> <serviceid></serviceid> IDD DVM Exchange 2.0 Page 14 of 29

15 Response <serviceid></serviceid> </services> </servicerequest> : <response requestid= > <services> <service> <Id></Id> <code></code> <reason></reason> </service> <service> <Id></Id> <code></code> <reason></reason> </service> </services> </response> References : IRS_DVM.022, IRS_DVM DVM Exchange 1.0 compliancy 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 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

16 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 trafficservice service Sequence : Description : trafficservice : 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 : 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 Message : <request clientid= serverid= requestid= time= > <networkmanagementrequest service= trafficservice > <controlparameter absolutevalue= relativevalue= /> <vehicletypes> </vehicletypes> <transporttypes> </transporttypes> </networkmanagementrequest> </request> Response : References : 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= > IDD DVM Exchange 2.0 Page 16 of 29

17 <networkmanagementrequest service= informationservice > <information></information> <vehicletypes> </vehicletypes> <transporttypes> </transporttypes> </networkmanagementrequest> </request Response : <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:soap=" <soap:body> <ns2:exchangeresponse xmlns:ns2=" <return> <response>accepted</response> <responsemessage>trafficservice with requestid [12345] accepted</responsemessage> </return> </ns2:exchangeresponse> </soap:body> </soap:envelope> References : reroutingservice service Sequence : Description : reroutingservice : Inform the traveller about an alternative route. Message : <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:soap=" <soap:body> <ns2:exchange xmlns:ns2=" <request clientid="nl.vialis.client" serverid="nl.vialis.server" requestid="12345" time=" t14:58:53.196cet"> <networkmanagementrequest service="reroutingservice"> <networkelementid>a10re_s116in</networkelementid> <priority>15</priority> <period>300</period> <information>rerouting info</information> <reroutingservicerequest destinationnetworkelementid="centrum" vianetworkelementid="a10re_s114in" /> </networkmanagementrequest> </request> </ns2:exchange> </soap:body> </soap:envelope> Response : <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:soap=" <soap:body> <ns2:exchangeresponse xmlns:ns2=" <return> <response>accepted</response> <responsemessage>rerouting service with requestid [12345] accepted</responsemessage> </return> </ns2:exchangeresponse> </soap:body> </soap:envelope> References : IDD DVM Exchange 2.0 Page 17 of 29

18 4.9.6 removeservice service Sequence : Description : RemoveService : 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 : <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:soap=" <soap:body> <ns2:exchange xmlns:ns2=" <request clientid="nl.vialis.client" serverid="nl.vialis.server" requestid="d88da14b-4a45-44b5-ad2e-efdf3e065538" time=" T14:58:53.743CET"> <controlrequest service="removeservice"> <removecontrolrequest> <targetrequestid>12345</targetrequestid> </removecontrolrequest> </controlrequest> </request> </ns2:exchange> </soap:body> </soap:envelope> Response : <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:soap=" <soap:body> <ns2:exchangeresponse xmlns:ns2=" <return> <response>accepted</response><responsemessage>service with requestid [12345] removed</responsemessage> </return> </ns2:exchangeresponse> </soap:body> </soap:envelope> References : getstatus Service Sequence : Description : getstatus : 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 IDD DVM Exchange 2.0 Page 18 of 29

19 status message Status message (optional, in case status is failed or unknown) Message : <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:soap=" <soap:body> <ns2:exchange xmlns:ns2=" <request clientid="nl.vialis.client" serverid="nl.vialis.server" requestid="c4707a74-fc19-492f-a2a2-071ca413d165" time=" T14:58:53.743CET"> <controlrequest service="getstatus"> <statuscontrolrequest> <targetrequestid>12345</targetrequestid> </statuscontrolrequest> </controlrequest> </request> </ns2:exchange> </soap:body> </soap:envelope> Response : <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:soap=" <soap:body> <ns2:exchange xmlns:ns2=" <request clientid="nl.vialis.client" serverid="nl.vialis.server" requestid="c4707a74-fc19-492f-a2a2-071ca413d165" time=" T14:58:53.743CET"> <controlrequest service="getstatus"> <statuscontrolrequest> <targetrequestid>12345</targetrequestid> </statuscontrolrequest> </controlrequest> </request> </ns2:exchange> </soap:body> </soap:envelope> References : IDD DVM Exchange 2.0 Page 19 of 29

20 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 Beheer IRS_DVM.001 IRS_DVM.002 IRS_DVM.003 IRS_DVM.004 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 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. 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. De interface is toe te passen zowel door overheidsinstanties als door private partijen. 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. Volgens de regels van een interface, wordt de interface alleen maar uitgebreid met nieuwe functionaliteiten terwijl de oude functionaliteiten zijn gewaarborgd. Dit kan worden gewaarborgd door de interface onder de GPL uit te brengen, of te beleggen bij een beheersorganisatie met deze condities. Dit kan worden gewaarborgd door de interface onder de GPL uit te brengen, of te beleggen bij een beheersorganisatie met deze condities NMS Client IRS_DVM.005 IRS_DVM.006 NMS Client moet voortdurend proberen verbinding te maken met DVM systeem / NMS server totdat de verbinding tot stand is gekomen 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.) 4.3 heartbeat 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 IDD DVM Exchange 2.0 Page 20 of 29

21 RequirementNo. Description Interface Remarks genomen door de client dat de dienst afneemt. De client beëindigd een sessie door een afmeldbericht te sturen. IRS_DVM.008 Een client moet de verbinding met DVM systeem / 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 4.3 heartbeat een sessie. Er dient derhalve ook geen afmeldbericht gestuurd te worden DVM Systeem / NMS Server IRS_DVM.010 IRS_DVM.011 IRS_DVM.012 IRS_DVM.013 IRS_DVM.014 IRS_DVM.015 IRS_DVM.016 IRS_DVM.017 IRS_DVM.018 IRS_DVM.019 Een server moet op een verbinding van NMS client wachten Elk commando van de client wordt direct beantwoord met een client bericht met daarij een toelichting als een commando niet kan worden uitgevoerd. Na aanmelding stuurt de server configuratieinformatie over alle DVM services en bijbehorende wegkantsystemen waarvoor de client rechten heeft. 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. Server moet als reactie op een configuratiecommando bericht van client een of meerdere configuratieberichten naar de client sturen. Statusinformatie van een scenario, een service of een wegkantsysteem wordt pas verstuurd nadat de configuratie van een object is verstuurd. 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. DVM Systeem / NMS Server moet een statusbericht sturen naar clients zodra de status of data van een scenario, DVM Service of wegkantsysteem is gewijzigd. Een server moet als reactie op het alive-bericht van een client een reply-bericht naar de betreffende client sturen. Als een server gedurende instelbare tijd geen berichten heeft ontvangen van een client, wordt ook 4.2 Generic 4.5 configupdate 4.5 configupdate 4.6 statusupdate 4.3 heartbeat 4.2 Generic 4.3 heartbeat Dit is standaard gedrag van een server Dit is omgedraaid. Bij opstarten haalt de client de configuratie op bij de server aangezien er geen sessie wordt gestart. Implementie van de software. Dit heeft niets met het protocol te maken. Implementatie van de software. Binnen een protocol zit geen validatie. IDD DVM Exchange 2.0 Page 21 of 29