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
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:
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
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:
INR-410 INR-420 System Administrator s Manual For V3.0.06 Version 2013/11/20 About This Manual Target Audience This manual is intended for System Administrators who are responsible for installing and setting
LevelOne User Manual ACC-2000 KVM IP Console Module Ver. 1.1 1 / 87 Certificates Ver. 1.0.0-0709 FCC This equipment has been tested and found to comply with Part 15 of the FCC Rules. Operation is subject
MFT Platform Server for Windows User Guide Version 7.1 September 28, 2011 Important Information MFT Platform Server for Windows Important Information SOME TIBCO SOFTWARE EMBEDS OR BUNDLES OTHER TIBCO SOFTWARE.
Yosemite Server Backup User s Guide Part number: First edition: October 2010 Legal and notice information Copyright 2004, 2012 Barracuda Networks, Inc. Under copyright laws, the contents of this document
Hotel Manual 2 Hotel Manual Hotel - System Setup Room Telephone Each telephone in a hotel room must be assigned in Hotel Room Extension Setup, this will allow the receptionist to check the room in/out,
Monitoring Network DMN User Manual Table of contents Table of contents... 2 1. Product features and capabilities... 3 2. System requirements... 5 3. Getting started with the software... 5 3-1 Installation...
User Manual V1.0 2008.10.23 Certifications FCC This equipment has been tested and found to comply with Part 15 of the FCC Rules. Operation is subject to the following two conditions: (1) This device may
Voipswitch Manual for version 340 and higher by Gabriel Georgescu 1 OVERVIEW 3 SOFTSWITCH 4 REQUIREMENTS. 10 PROGRAM INSTALLATION. 10 LAUNCHING THE MAIN APPLICATION VOIPSWITCH 12 GATEWAYS 18 GK/REGISTRAR
IDEP FOR WINDOWS USER MANUAL Version 2011 BE National Accounts Institute National Bank of Belgium External statistics Boulevard de Berlaimont 14 B-1000 Brussels Table of contents 1 INTRODUCTION.... 1 1.1
Getting Started Guide StarTeam Borland Software Corporation 100 Enterprise Way Scotts Valley, California 95066-3249 www.borland.com Borland Software Corporation may have patents and/or pending patent applications
User Manual CENTRAL MANAGEMENT SOFTWARE CMS Remote Monitoring Software for Q-See s QT-Series DVRs 1 Thank You for Choosing a Q-See Product! All of our products are backed by a conditional service warranty
Version: 2011-11-28 UPS-Management Software (UPSMAN, UPSMON, UPS View, UNMS) User Manual Copyright Statement for Intellectual Property and Confidential Information The information contained in this manual
icar itrain for Modelcars Dinamo/MCC Manual 2.0 2014 This manual is written and supplied by MCC-ModelCarParts. This document, or any information contained herein, may not in whole or in parts be copied
ESET Remote Administrator Installation Manual and User Guide we protect your digital worlds contents Contents 1. Introduction... 4 2. ERA client/server architecture... 5 2.1 ERA Server (ERAS)...5 2.1.1
USER S MANUAL AXIS M3011 Network Camera AXIS M3011 User s Manual Notices This manual is intended for administrators and users of the AXIS M3011 Network Camera, and is applicable for firmware release 5.0
UNIFACE Configuration Guide UNIFACE V7.2 10115087204-01 Revision 1 Mar 1999 CFG UNIFACE Configuration Guide Revision 1 Restricted Rights Notice This document and the product referenced in it are subject
CW-720 720P Wireless 150Mbps IPCAM User s Manual i Copyright & Disclaimer Copyright & Disclaimer No part of this publication may be reproduced in any form or by any means, whether electronic, mechanical,
USER S MANUAL AXIS Q1755 Network Camera AXIS Q1755 - Notices Notices This manual is intended for administrators and users of the AXIS Q1755 Network Camera, and is applicable for firmware release 5.01 and
Total Connect TM 2.0 Online Help Guide Hints for use: When viewing in a web browser, hit F11 to toggle full screen mode. Use the bookmarks panel or table of contents to jump to the desired topic. Select
Administration Manual Web Security Manager 4.2 www.alertlogic.com email@example.com February, 2014 Alert Logic, the Alert Logic logo, the Alert Logic logotype and Web Security Manager are trademarks
16-Channel VoIP Gateway Card Getting Started Model No. KX-TDA0490 Thank you for purchasing a Panasonic 16-Channel VoIP Gateway Card. Please read this manual carefully before using this product and save