New Item added for scanning of sign display CHA CHA. SetLock Key not saved by client software ESP

Transcription

1 H New Item added for scanning of sign display CHA CHA G SetLock Key not saved by client software ESP F SetBrightness_CD rw Correct noenum/enumerated for Aux items Removed enum for SetActiveLibrary/StatusActiveLibrary,SetBrightness FontType -> SetFontType ELP ESP E SetLibraryCount removed Lock* items introduced ESP CHA Rev. Rettelse Dato Tegnet Kontrol Godkendt

2 Q:\4380\4382\ M13 HILLERØDMOTORVEJEN ITS-AFDELINGEN Sign-XML-DA v. 3.0 Protocol Specification Proj. ESP Tegnet ESP Kontrol. CHA Godk. Tegn. Nr. KH Dato Rev. DH H

3 Purpose This document specifies the interface between various traffic components and their clients, which is to manage the overall control and monitoring of the signs. In this document sign is used as an umbrella term which also covers Aux, UPS, and Detector which all use the Sign-XML-DA protocol. Therefore this specification applies to both the suppliers of variable traffic message signs and the suppliers of traffic control systems. The interface has been developed for traffic management systems in order to facilitate the establishment of one interface between a management system and all kinds of variable traffic signs. The interface has been developed to be used for communication with all possible types of variable message signs be based on the standard protocol TCP/IP and the standard methods HTTP/HTTPS and SOAP. be used for development of a flexible traffic management system, which can be easily adapted when: New variable signs have been installed Variable signs have been removed or relocated. The basic display facilities of the signs have been modified. The interface has been named Sign-XML-DA and it specifies: Design and contents of telegrams by means of which communication between clients and the variable traffic signs is to be carried out. Services which are to be executed on the clients, hereinafter called the Sign-XML-DA-client. Services that have to be executed on the variable traffic signs, hereinafter called Sign-XML-DA-server.

4 1. Contents 1. CONTENTS INTRODUCTION REVISION INFO NETWORK TRAFFIC SIGNS AND FUNCTIONS NAMESPACE ITEMS Status Alarms Control Management Identification OPC XML-DA, STATUS GetStatus (Client) GetStatusReponse (Sign Control Unit) READ Read (Client) ReadResponse (Sign Control Unit) WRITE Write (Client) WriteResponse (Sign Control Unit) SUBSCRIBE Subscribe (Client) SubscribeResponse (PortalServer /Sign Control Unit) SUBSCRIPTIONPOLLEDREFRESH SubscriptionPolledRefresh (Client) SubscriptionPolledRefreshResponse SUBSCRIPTIONCANCEL, BROWSE AND GETPROPERTIES COMMUNICATION AND FLOW TIME CONTROL MANAGEMENT MONITORING IDENTIFICATION LOG ON STRUCTURE DEPRECATED DATATYPES XML-DA ITEMS, EXPLANATIONS ROOT int StatusOperationMode int StatusGeoPositionLatitude int StatusGeoPositionLongitude int StatusDirection string StatusLocation boolean AlarmVoltageBreakOccurred boolean AlarmVoltageFault boolean AlarmEquipment... 31

5 9.1.9 boolean AlarmLocalOperationTimeOut boolean AlarmTempHigh boolean AlarmTempLow boolean AlarmDoorOpen string AlarmCode datetime SetDateTime int SetOperationMode int SetLocalOperationModeTime boolean ResetAlarmVoltageBreakOccurred string SetLocation String ComponentType String ProtocolVersion AUX float SetAnalogIO_x float StatusAnalogIO_x boolean SetDigitalIO_x boolean StatusDigitalIO_x datetime SetTimeOfAnalogIOActivating datetime SetTimeOfDigitalIOActivating UPS boolean AlarmUPSFailure boolean AlarmMainSupplyFailure SIGN int StatusSign String StatusDisplayImage String StatusDisplayScanning String StatusActiveLibrary float StatusLightSensor int SignWidth int SignHeight String SetActiveLibrary boolean SetTestMode datetime SetTimeOfLibraryActivating String SetValueForDefaultLibrary String SetLock String SetUnLock boolean StatusLocked DETECTOR int StatusDetector int StatusTrafficSpeedArit int StatusTrafficSpeedHarm boolean AlarmTrafficEvent boolean AlarmWrongVehicleDirection boolean AlarmQueue boolean AlarmVehicleDetection boolean AlarmHighVehicle string DetectorType GRAPHIC SIGN float StatusBrightness float StatusBrightnessCD String StatusErrorMap boolean AlarmWrongDisplayInfo boolean AlarmLEDModuleError boolean AlarmModuleError... 45

6 9.6.7 int SetLEDModuleError int SetBrightness float SetBrightnessCD datetime SetTimeOfBrightnessActivating int NumberOfModulesHorisontal int NumberOfModulesVertical int Colours int ModulePixelHorisontal int ModulePixelVertical int SignPixelHorisontal int SignPixelVertical STATICSIGN boolean AlarmSignLightingError boolean StatusSignLighting boolean SetSignLighting FIXEDSIGN ArrayOfString SetLibrary_ TEXTSIGN int NumberOfLines ArrayOfString SetLibrary_ ArrayOfString SetLibrary_x float SetRelativeLineSpacing float SetRelativeLetterSpacing string SetFontType int NumberOfCharactersPerLine FULLYGRAPHICSIGN ArrayOfString SetLibrary_x ArrayOfString SetLibrary_ PRISMFIXEDSIGN boolean AlarmPositionUnknown ArrayOfString SetLibrary_ ArrayOfString SetLibrary_x, for x = TRANSLATION OF CHARACTERS REFERENCES... 61

7 2. Introduction Because of the wide range of variable traffic signs, Signs with fixed displays Fully graphic signs with facilities for several colours Text-based signs with fixed and variable character displays and the need of central control, it is necessary to find a uniform way of communicating with the traffic signs by means of a traffic management system. The Sign-XML-DA is an extension and clarification of the OPC XML-DA specification that can be found at 3. Revision info This issue of the Sign-XML-DA interface version 3.0 beta is based on the previous version 2.1. The major change is the handling of libraries which is now different since gif files are sent as base64 encoded strings and not as SOAP attachments. Because of this change the protocol is no longer backwards compatible with previous versions of SIGN-XML-DA. In addition, the component objects Detector, UPS and Aux are now added to the protocol. Because of this addition the sign object is split into a new object called Root and the previous object called Sign. The term component is now used for what was called sign object in previous protocol versions. Changes from SIGN-XML-DA 2.1 1) Uses Base64 for sending gif over SOAP. SOAP with attachments are not used. 2) New object hierarchy. Root as base for all types. 3) Detector, Aux, UPS types added. 4) MatrixTextSign, LineMatrixSign removed. TextSign has same functionality. 5) Several items moved from one type to another. 6) TextSign supports justificatino of text, variable line, letter spacing. 7) Unlimited number of libraries for Signs, uses string as identifier. 8) Removed danish item and type names. 9) Sign: Added SetTestMode 10) Root: Added ComponentType, ProtocolVersion, AlarmTempHigh, AlarmTempLow, AlarmDoorOpen, SetLocation, StatusLocation. 11) GraphicSign: added StatusErrorMap, StatusBrightNessCD, SetTimeOfBrightnessActivating. Changed colours 12) FixedSign: Added StatusSignLighting, SetSignLighting

8 13) TextSign: Added RelativeLineSpacing, RelativeLetterSpacing. Changed SetLibrary_x, SetFontType, removed item SetFont 14) SignType, StatusDisplayInfo renamed. StatusBrightness changed. 15) Connection between Local operation and Subscription 16) Access rights changed to ReadWritable for items: 17) SetValueForDefaultLibrary 18) SetActiveLibrary 19) SetOperationMode 20) SetDateTime 21) SetLocalOperationModeTime 22) Namespace extended to include detector data. New detector items are: a. StatusDetector b. StatusTrafficSpeed1 c. StatusTrafficSpeed2 d. AlarmTrafficEvent e. AlarmWrongVehicleDirection f. AlarmQueue g. AlarmVehicleDetection h. AlarmHighVehicle i. DetectorType 23) Namespace extended to include aux data. New Aux items are: a. SetAnalogIO_x b. StatusAnalogIO_x c. SetDigitalIO_x d. StatusDigitalIO_x e. SetTimeOfAnalogIOActivating f. SetTimeOfDigitalIOActivating 24) Namespace extended to include UPS data. New UPS items are: a. AlarmUPSFailure b. AlarmMainSupplyFailure 25) Service attribute ReturnAllItems to service SubscriptionPolledRefresh can be false or true. 26) New items added: StatusLocation; SetLocation 27) New enum value (remote control) added for the items 28) No explicit dynamic effects for GraphicSign libraires. Libraries can be animated gif. 29) No special meaning to libraries 50, 100(user libraries). All libraries are considered user libraries. 30) Signs are required to keep correct time. By NTP or other means. 31) SetLock/SetUnlock/StatusLocked 32) New item: StatusDisplayScanning

9 1. A sign control unit is a separate sign, where the respective users only will have access to one physical sign. 4. Network The traffic signs shall be able to communicate through TCP/IP, using HTTP Port 80 / HTTPS port 443. Where nothing else has been agreed between the parties, the HTTP port 80 shall be used as default. HTTP Basic Authentication shall be used. (cf. ref. 3). It shall be possible to configure the traffic signs individually to arbitrary, fixed IP addresses. The addresses of the signs shall comply with below guidelines for http addresses: 1. xxx.xxx.xxx.xxx signifies an IP address e.g Clients must be prepared for any http URL for testing purposes. 5. Traffic Signs and Functions The below figure clarifies the different interfaces and the functions that need to be included in Sign-XML-DA. Portal server / sign control unit <<traffic sign>> graphical <<traffic sign>> Text <<traffic sign>> Line IT central control Local control Control and monitoring Sign control <<traffic sign>> Sign <<traffic sign>> FullyGraphic <<traffic sign>> Matrix <<User>> Local <<traffic sign>> Fixed <<traffic sign>> Prism Figure 1 Sign functions and interfaces. A frame called a Portal Server/Sign control unit has been marked, which should be understood in the following way:

10

11 Represents a user, a unit or a system. Actor Use Case Generalisation Describes the performance of the system, a sequence of actions that the system performs. A relation between a general element and a more specific element. Base Use Case includes the relevant Use Case. Describes an extension of the actions of a Use Case Association Attaches an Actor to a Use Case. Shows the participation of an Actor in a Use Case. Control and monitoring system Status Read Write Browse Get Properties Subscription Subscription Polled Refresh Subscription Cancel Local Sign Control and monitoring of the traffic signs is accomplished according to the OPC-XML-DA (Ref.2) Reference is made to the OPC-XML-DA specification (Version 1.0.1), section 3.2 for detailed description of service. Reference is made to the OPC-XML-DA specification (Version 1.0.1), section 3.3 for detailed description of service. Reference is made to the OPC-XML-DA specification (Version 1.0.1), section 3.4 for detailed description of service. Reference is made to the OPC-XML-DA specification (Version 1.0.1), section 3.8 for detailed description of service. Reference is made to the OPC-XML-DA specification (Version 1.0.1), section 3.9 for detailed description of service. Reference is made to the OPC-XML-DA specification (Version 1.0.1), section 3.5 for detailed description of service. Reference is made to the OPC-XML-DA specification (Version 1.0.1), section 3.6 for detailed description of service. Reference is made to the OPC-XML-DA specification (Version 1.0.1), section 3.7 for detailed description of service. Service staff or the like, who controls and monitors the traffic signs locally in connection with trouble shooting and testing. Overall term for a sign that is common to all types of signs.

12 Graphic Overall term for signs that use LED for displays. Fully graphic display (Category 3) Arbitrary symbols can be displayed using one or more colours e.g.: FullGraphic Text Overall term for text signs that are common to all types of text signs. Detector Aux UPS Overall term for a detector that are common to all types of detectors. Used for bringing legacy equipment into a new system. Can control and read arbitrary analog and digital inputs. Uninterruptible power supply. Used for monitoring overall health of UPS and main supply. Line matrix (Category 2). Lines X numbers of lines with text can be displayed with a floating number of characters, depending on the size of the characters used. (Different colours, fonts etc.) Text matrix (Category 2). Matrix X numbers of lines with text can be displayed with a fixed number of characters e.g.: Fixed Varieties of fixed signs could be prisms, barriers, flashing stop lights, etc.

13 Prism Prism Sign (Category 1). Fixed libraries are used. Typically, there will be 3 fixed libraries that can be set by rotating the segments of the sign. Local control Sign control TCP/IP - HTTP connection where communication is done through SOAP. A portal server uses TCP/IP HTTP, and a sign server may use a proprietary protocol. Sign-XML-DA is in its present shape based on control/monitoring of above types of variable signsm UPS, Aux and detectors. However, the protocol is designed to control/monitor any possible type of variable sign/marking (flashing stop lights, barriers, traffic signals etc.) It should be possible to an arbitrary number of libraries in each sign, so that the clients can activate libraries stored in the signs (Fixed signs need, however, not go beyond a fixed number of libraries). Library_0 is an item; however, it always means that the sign shall be blank. This library can therefore not be loaded with any value, but if it is read, the sign shall return a blank GIF image. There shall be a default library that shall be used if errors occur so that the sign automatically switches to this library in case of lack of communication, sign errors, etc. It shall also be possible to upload new sign values to the libraries of the signs. (Sign values can be text strings or base64 encoded gif images). The signs shall be provided with mechanisms that make it possible to report errors. This protocol lays down some minimum requirements that must be complied with. Figure 2 System

14 If the Sign Control Unit lose the connection to the display, it shall set the server state to commfault.

15 6. Namespace The Sign-XML-DA protocol is using a object oriented design, meaning only the items specified in a given type and parent types is implemented. Example: The type TextSign implements the items in TextSign, GraphicSign, Sign, Root. TextSign does not implement the items in StaticSign, FixedSign, PrismFixedSign, Detector, Aux, UPS. According to Figure 3 the following signs, detector and object structure have been defined: Figur 3 Object oriented structure of namespace with the different sign types and the additional objects detector and object. All types inherit properties from upper level type. Rounded corners in this drawing indicates an abstract type. Squared corners indicate concrete types. Namespaces have been designed according to OPC XML-DA (naming of items). Kunne ikke finde tekst til indholdsfortegnelsen.

16 Example: the value from the item SignType can be fetched from the sign, with the SignID Sign123 by the following xml-message: <soap:body> <Read xmlns= > <Options ReturnErrorText= true ReturnItemTime= true ReturnItemName= true LocaleID= en-dk /> <ItemList> <Items ItemName= Sign123/Identification/SignType /> </ItemList> </Read> </soap:body> Sign123 is the ID of the sign which will be returned is ItemName is the empty string. Identification is the ItemGroup of the item, and SignType is the ItemName. 6.1 Items Status Monitoring/Status/StatusOperationMode Monitoring/Status/StatusGeoPositionLatitude Monitoring/Status/StatusGeoPositionLongitude Monitoring/Status/StatusDirection Monitoring/Status/StatusLocation Monitoring/Status/StatusDigitalIO_x Monitoring/Status/StatusAnalogIO_x Monitoring/Status/StatusSign Monitoring/Status/StatusDisplayImage Monitoring/Status/StatusDisplayScanning Monitoring/Status/StatusActiveLibrary Monitoring/Status/StatusLightSensor Monitoring/Status/StatusDetector Monitoring/Status/StatusTrafficSpeedArit Monitoring/Status/StatusTrafficSpeedHarm Monitoring/Status/StatusBrightness Monitoring/Status/StatusBrightnessCD Monitoring/Status/StatusErrorMap Monitoring/Status/StatusSignLighting Monitoring/Status/StatusLocked Alarms Monitoring/Alarms/AlarmVoltageBreakOccurred Monitoring/Alarms/AlarmVoltageFault

17 Monitoring/Alarms/AlarmEquipment Monitoring/Alarms/AlarmLocalOperationTimeOut Monitoring/Alarms/AlarmTempHigh Monitoring/Alarms/AlarmTempLow Monitoring/Alarms/AlarmDoorOpen Monitoring/Alarms/AlarmCode Monitoring/Alarms/AlarmUPSFailure Monitoring/Alarms/AlarmMainSupplyFailure Monitoring/Alarms/AlarmTrafficEvent Monitoring/Alarms/AlarmWrongVehicleDirection Monitoring/Alarms/AlarmQueue Monitoring/Alarms/AlarmVehicleDetection Monitoring/Alarms/AlarmHighVehicle Monitoring/Alarms/AlarmWrongDisplayInfo Monitoring/Alarms/AlarmLEDModuleError Monitoring/Alarms/AlarmModuleError Monitoring/Alarms/AlarmSignLightingError Monitoring/Alarms/AlarmPositionUnknown Control Control/SetAnalogIO_x Control/SetDigitalIO_x Control/SetValueForDefaultLibrary Control/SetTimeOfBrightnessActivating Control/SetTimeOfLibraryActivating Control/SetSignLighting Control/SetActiveLibrary Control/SetTimeOfDigitalIOActivating Control/SetTimeOfAnalogIOActivating Control/SetLock Control/SetUnlock Management Management/SetLocation Management/SetOperationMode Management/SetLocalOperationModeTime Management/ResetAlarmVoltageBreakOccurred Management/SetLEDModuleError Management/SetBrightness Management/SetDateTime Management/SetBrightnessCD Management/SetLibrary_1 Management/SetLibrary_0 Management/SetLibrary_x Management/SetRelativeLineSpacing

18 Management/SetRelativeLetterSpacing Management/SetTestMode Identification Identification/ComponentType Identification/ProtocolVersion Identification/SignWidth Identification/SignHeight Identification/DetectorType Identification/NumberOfModulesHorisontal Identification/NumberOfModulesVertical Identification/Colours Identification/ModulePixelHorisontal Identification/ModulePixelVertical Identification/SignPixelHorisontal Identification/SignPixelVertical Identification/NumberOfLines Identification/NumberOfCharactersPerLine Identification/SetFontType Refer to chapter 9 for explanations of items. 7. OPC XML-DA, In the following section, attention will be drawn to the extensions and definitions of the OPC XML-DA specification. Where nothing else is stated in this specification, the OPC XML-DA shall apply. No other result codes (OPCError) shall be used than those specified by the OPC XML-DA specification Should proprietary error codes be required, such codes shall be discussed with the Danish Road Directorate prior to use to facilitate an update of this present standard. The ErrorText shall be designed following below principle: SignID.Component.Element alarmdescription

19 7.1 Status When the client/server requests/answers a status the following instructions shall be followed: GetStatus (Client) LokalID shall be dk-dk or en-dk. Example : <soap:body> <GetStatus LocaleID= dk-dk Xmlns= /> /> </soap:body> GetStatusReponse (Sign Control Unit) StatusInfo shall be filled in with the following comma-separated information: Sign software (Main modules + version), Sign-XML-DA version VendorInfo shall be filled in with the following comma-separated information: Company Name, Address, Telephone

20 Example: <soap:body> <GetStatusResponse xmlns= /> <GetStatusResult RcvTime= T14:01: :00 ReplyTime= T14:01: :00 ServerState= running /> <Status StartTime= T12:04: :00 ProductVersion= > <StatusInfo>Windows XP Professional SP2, Tomcat Webserver 4.1</StatusInfo> <VendorInfo>Vejdirektoratet, Niels Juuls gade 13, , Sign-XML-DA 2.0</VendorInfo> <SupportedLocaleIDs>da</SupportedLocaleIDs> <SupportedInterfaceVersions>XML_DA_Version_2_0 </SupportedInterfaceVersions> </Status> </GetStatusResponse> 7.2 Read When the client/server requests/answers a Read service, the following instructions shall be followed: Read (Client) ReturnDiagnosticInfo shall be true (the server shall be provided with information regarding a trouble shooting guide) so that the Client can use this information as help text for trouble shooting. ReturnItemTime shall be true so that a log, if any, can be provided with a time stamp. LokalID shall be da-dk or en-dk. Example: <soap:body> <Read xmlns= > <Options ReturnErrorText= true ReturnDiagnosticInfo= true ReturnItemTime= true LocalID= en-dk /> <ItemList> <Items ItemName= Sign123/Management/SetSignPosition /> <Items ItemName= Sign123/Management/SetDateTime /> </ItemList> </Read> </soap:body>

21 7.2.2 ReadResponse (Sign Control Unit) OPCQuality shall use either QualityField or LimitField. VendorField shall not be used unless this has been agreed and inserted in this present specification. 7.3 Write When the client/server requests/answers the Write service the following instructions shall be followed: Write (Client) ReturnDiagnosticInfo shall be true (the server shall be provided with information regarding a trouble shooting guide) so that the client can use this information as help text for troubleshooting. ReturnItemTime shall be true so that a log, if any, can be provided with a time stamp. LokalID shall be da-dk or en-dk. ReturnValuesOnReply shall always be true since a verification of data from the sign is important. When the libraries are set, RequestDeadline can be used to ensure a series of writings on a number of signs within a certain period. The client shall, however, be aware that the transfer of graphic files can delay the response time.

22 Example: <?xml version='1.0'?> <soap:envelope xmlns:soap= xmlns:xsi= xmlns:xsd= > <soap:body> <Write ReturnValuesOnReply= true xmlns= > <Options ReturnErrorText= true ReturnDiagnosticInfo= true ReturnItemTime= true RequestDeadline= T14:00: :00 LocalID= en-dk /> <ItemList> <Items ItemName= Sign123/Management/SetLibrary_2 > <Value xsi:type= xsd:arrayofstring > <string>91-2</string> <string>queue</string> </Value> </Items> <Items ItemName= Sign123/Control/SetActiveLibrary > <Value xsi:type= xsd:byte >2</Value> </Items> <Items ItemName= Sign123/Control/SetTimeOfLibraryActivating > <Value xsi:type= xsd:datetime > T14:05: :00 </Value> </Items> </ItemList> </Write> </soap:body> </soap:envelope> Please note that it has been decided that the sign shall read items after receipt and return them to the client, and that it shall take place within a specified RequestDeadLine.

23 LokalID shall be da-dk or en-dk WriteResponse (Sign Control Unit) OPCQuality shall use either QualityField or LimitField. VendorField shall not be used unless this has been agreed and inserted in this present specification. Example: <soap:body> <WriteResponse xmlns= > <WriteResult RcvTime= T14:01: :00 ReplyTime= T14:01: :00 ServerState= running /> <RItemList> <Items ItemName= Sign123/Management/SetLibrary_2 Timestanp= T14:01: :00 > <Value xsi:type= xsd:arrayofstring > <string>91-2</string> <string>queue</string> </Value> </Items> <Items ItemName= Sign123/Control/SetActiveLibrary Timestanp= T14:01: :00 > <Value xsi:type= xsd:byte >2</Value> </Items> <Items ItemName= Sign123/Control/SetTimeOfLibraryActivating Timestanp= T14:01: :00 > <Value xsi:type= xsd:datetime > T14:05: :00 </Value> </Items> </RItemList> </WriteResponse> </soap:body> </soap:envelope> 7.4 Subscribe When client/server requests/answers the Subscribe service, the following instructions shall be followed: Subscribe (Client) ReturnDiagnosticInfo shall be true (the server shall be provided with information regarding a trouble shooting guide) so that the client can use this information as help text for troubleshooting. ReturnItemTime shall be true so that a log, if any, can be provided with a time stamp.

24 SubscriptionPingRate shall be a variable client parameter and shall be supported by the sign at the interval of ms. In case of lack of communication, (SubscriptionPingRate expired) and if the sign is not in local control mode, the sign shall neutralize the display (i.e. StatusActiveLibrary = SetValueForDefaultLibrary). If the sign is in local control mode, the StatusActiveLibrary is retained. RequestedSamplingRate depends on the sign. The client can use this item to receive a RevisedSamplingRate in order to determine the minimum limit of the sign. It is a good idea to spare the sign for stressing pollings by setting HoldTime and WaitTime on the client. These items should be set according to the response times required. EnableBuffering must be false.

25 <soap:body> <Subscribe SubscriptionPingRate= 3000 xmlns= > <Options ReturnErrorText= true ReturnDiagnosticInfo= true ReturnItemTime= true LocalID= en-dk /> <ItemList RequestedSamplingRate= 3000 > <Items ItemName= Sign123/Management/SetLibrary_2 ClientItemHandle= e03err2-r34t-4er3-re3443 /> <Items ItemName= Sign123/Control/StatusActiveLibrary ClientItemHandle= e04edf5-r3df-4e53-re3663 /> </ItemList> </Subscribe> </soap:body> SubscribeResponse (PortalServer /Sign Control Unit) This service is used as described in the OPC XML-DA specification 1.0, section (See also examples in this section). 7.5 SubscriptionPolledRefresh When the client/server requests/answers a SubscriptionPolledRefresh service, the following instructions shall be followed: SubscriptionPolledRefresh (Client) ReturnDiagnosticInfo shall be true (the server shall be provided with information regarding a trouble shooting guide), so that the client can use this information as help text for troubleshooting. ReturnItemTime shall be true so that a log, if any, can be provided with a timestamp. LokalID shall be en-dk. HoldTime must be applied, and the default value shall be 3000 ms. (In the SubscriptionPolledRefresh service this time value must be defined in absolute time related to the current time, see example). WaitTime must be applied, and the default value shall be ms. ReturnAllItems can be true or false.

26 Example : <soap:body> <SubscriptionPolledRefresh Holdtime= T15:00: :00 Waittime= ReturnAllItems= false xmlns= > <Options ReturnErrorText= true ReturnDiagnosticInfo= true ReturnItemTime= true LocalID= en-dk /> <ServerSubHandles>f6f8700g jdhg</ServerSubHandles> </SubscriptionPolledRefresh> </soap:body> SubscriptionPolledRefreshResponse This service is used as described in the OPC XML-DA specification 1.0, section (See also examples in this section). 7.6 SubscriptionCancel, Browse and GetProperties SubscriptionCancel, Browse and GetProperties shall be used as described in the OPC XML-DA specification 1.0, (See also examples in the sections). LokalID shall be da-dk or en-dk.

27 8. Communication and Flow The following sections describe the different interactions that shall be observed by the client/server, as well as information exchange. The following overall terms apply: 1. Control Control includes all active processes that require writing to the graphic sign in order to set the sign in a new state. 2. Management Management includes all processes that require Read/Writing to manage the configuration of the component. 3. Monitoring Monitoring includes all the processes that handle evaluation of component conditions; on this basis logic control or management may be activated. 4. Identification Identification includes information that is necessary for correct identification of the component, so that the client can make the appropriate control tools, editing tools, etc. available to the user. It should be noted that the four terms undeniably interact with each other and therefore they may cause mutual activation. 8.1 Time Signs must always know the current time. It is the responsibility of the sign to keep time updated. If the sign uses NTP, there must be a configuration interface to set the time server. 8.2 Control Control includes items in the group Control. The following services are used for control: Read Write When setting a new active library and activating time, the sign shall always follow the new values and thus cancel ongoing jobs in such a way that activations not carried out are cancelled by the new values. 8.3 Management Management includes items in the group Management. The following services are used for management: