Andover Continuum Security and TAC I/A Series Data Exchange Reference Guide

(1)

Andover Continuum Security and

TAC I/A Series

(2)

No part of this publication may be reproduced, read or stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission of Schneider Electric.

All brand names, trademarks and registered trademarks are the property of their respec-tive owners. Information contained within this document is subject to change without no-tice. Distributed, manufactured and sold by Schneider Electric. I/A Series trademarks are owned by Invensys Systems, Inc. and are on this product under license from Invensys. In-vensys does not manufacture this product or provide any product warranty or support. For service, support and warranty information, contact Schneider Electric at 1-888-444-1311. This document is produced in the United States of America.

Title: Andover Continuum Security and TAC I/A Series Data Exchange Reference Guide

Revision: B

Date: December, 2010

Schneider Electric part number: 30-3001-406 Software application version number 1.81 or higher

The information in this document is furnished for informational purposes only, is subject to change without notice, and should not be construed as a commitment by Schneider Elec-tric. Schneider Electric assumes no liability for any errors or inaccuracies that may appear in this document.

Schneider Electric One High Street

North Andover, MA 01845 (978) 975-9600

Fax: (978) 975-9782

(3)

December, 2010

Andover Continuum Security and TAC

I/A Series Data Exchange Reference Guide

30-3001-406 Revision B

(4)

(5)

Contents

Standard Regulatory Notices for Andover Continuum Hardware

5

Federal Communications Commission ... 5

Industry Canada ... 5

CE - Compliance to European Union (EU) ... 5

Australian Communications Authority (ACA) ... 6

WEEE - Directive of the European Union (EU) ... 6

RoHS - Restriction of Hazardous Materials ... 6

UL Listing ... 6

About this Manual ...

9

What’s in this Manual ... 9

Symbols Used ... 10

Chapter 1

Introduction and System Overview ...

11

TAC I/A Series and Andover Continuum Security Solution ... 12

Purpose of this Document ... 12

System Architecture ... 13

Key Concepts and Nomenclature ... 14

Access Control System ... 14

Network ... 14

Andover Continuum ... 14

ACX 57xx Series Controller ... 15

Port ... 15

CyberStation ... 15

Database ... 16

Plain English Programs ... 16

(6)

XDriver SelfObject ... 17

XDriver Client Object ... 17

XDriver Server Object ... 17

Door ... 18 Door Attributes ... 18 Events ... 18 Alarms ... 18 Schedules ... 18 User ... 19 Programmer ... 19

Supported Device Configurations ... 20

Workplace Tech/MNB-1000 Controller/ACX 57xx/CyberStation 20 Enterprise Server/UNC/ENC Controller/ACX 57xx/CyberSta-tion ... 21

Enterprise Server/web.Client - 2 machine ... 21

Enterprise Server/web.Client/CyberStation - 3 machine 22 Multiple ACX 57xx Controllers ... 22

Role of XDriver and Plain English in Integration ... 23

Role of XDriver Points ... 23

Role of PE Programs ... 23

Chapter 2

CyberStation ...

25

Introduction ... 26

System Requirements and Pre-Installation ... 27

Minimum/Recommended Hardware Requirements ... 27

Software Requirements ... 27

Overview of Common CyberStation Tools and Tasks ... 30

ACX 57xx Controller Update/Configuration ... 30

XDriver Support ... 30

Creating Points ... 30

To create a point ... 31

PE Programs ... 32

web.Client for Web-based Access ... 33

Chapter 3

Using the BACnet/IP XDriver ...

35

BACnet/IP XDriver Overview ... 36

(7)

BACnet/IP XDriver Installation ... 37 Configuration ... 39 Overview ... 39 Parameters ... 40 Point Access ... 41 Type ... 42 Instance ... 42 ... 43 Property ... 43 BACnet Network ... 44 IP Address ... 44

BACnet XDriver Points Overview ... 47

Client BACnet XDriver Points ... 47

Examples of a Client BACnet XDriver Point ... 48

Server BACnet Points ... 51

Example 1 Server BACnet Point ... 52

Example 2 Server BACnet Point with Engineering Units ... 53

Example 3 Server BACnet Point with Engineering Units, Relinquish Default, and Priority Level ... 54

...DeviceS-elf Object ... 55

Programming Introduction ... 60

Plain English Programming Language ... 60

Programming Examples - Single ACX 57xx Controller ... 60

Program Type 1 Distribute Door Attribute Values to MNB-1000 or UNC/ ENC Controllers When a Persistent Door Attribute Changes ...61

Program Type 2 Modify Door Attribute Values from MNB-1000 or UNC/ENC Controllers ... 63 Program Type 3

Distribute Door Attribute Values to MNB-1000 or UNC/ ENC Controllers When a One-Scan Door Attribute Changes 64

(8)

ENC Controllers when a Persistent Door Attribute Changes

in the SecondACX ... 66

Program Type 2 Modify Door Attribute Values in SecondACX from MNB-1000 or UNC/ENC Controllers ... 67

Program Type 3 Distribute Door Attribute Values to MNB-1000 or UNC/ ENC Controllers When a One-Scan Door Attribute Changes in SecondACX ... 68

Chapter 4

web.Client ...

69

web.Client Overview ... 70

web.Client User Documentation ... 71

A Typical System before web.Client ... 72

A Typical System Implementing web.Client ... 73

Differences between web.Client and CyberStation ... 75

Hardware and Software Requirements for LAN System ... 76

Hardware and Software Requirements for a Standalone System 79

Appendix A

Supported Access

Control Elements ...

83

Appendix B

Best Practices ...

91

Tips for Successful Implementation ... 92

Appendix C

Industry Canada

ICES-003

This is a Class A digital device that meets all requirements of the Canadian Interference Causing Equipment Regulations.

CE - Compliance to European Union (EU)

2004/108/EEC - EMC Directive

This equipment complies with the rules of the Official Journal of the European Communities specified in the EMC

(10)

Regulatory Notices

Australian Communications Authority (ACA)

AS/NZS 3548

This equipment carries the C-Tick label and complies with EMC and radio communications regulations of the

Australian Communications Authority (ACA), governing the Australian and New Zealand communities.

WEEE - Directive of the European Union (EU)

2002/96/EC

This equipment and its packaging carry the waste electrical and electronic equipment (WEEE) label, in compliance with European Union (EU) Directive 2002/96/EC, governing the disposal and recycling of electrical and electronic equipment in the European community.

RoHS - Restriction of Hazardous Materials

2002/95/EC

This product complies with the restriction of the use of certain hazardous substances in the European Union electrical and electronic equipment directive.

UL Listing

UL 916

UL listed product for the United States and Canada: Open Energy Management Equipment

(11)

Regulatory Notices

CAUTION

All pertinent state, regional, and local safety regulations must be observed when installing and using this product.

For reasons of safety and to assure compliance with documented system data, repairs to components should be performed only by the manufacturer.

Failure to observe this precaution can result in injury or equipment damage.

(12)

(13)

About this Manual

What’s in this Manual

z Chapter One - Introduction and System Overview: This chapter contains a basic look at what the Andover Continuum Security and TAC I/A Series solution is and how it works. It contains information regarding nomenclature, supported devices and the system

integration between I/A Series and Andover Continuum products. z Chapter Two - CyberStation: This chapter focuses on the

Continuum CyberStation software that is used to perform certain functions within the security solution.

z Chapter Three - Using the BACnet/IP XDriver: This chapter explains the BACnet XDriver data exchange solution for access control. Installation, configuration and programming examples are covered in this section.

z Chapter Four - web.Client: This chapter introduces the web.Client internet-based tool for use with the security solution. This is an additional resource for use with the Andover Continuum Security and TAC I/A Series security solution.

z Appendix A - Supported Access Control Elements: This appendix is a spreadsheet view of the devices and attributes supported by this security solution.

z Appendix B - Best Practices: This section of the reference guide provides hints and suggestions for successful implementation of the security solution. Common issues and questions relating to this data exchange are covered.

z Appendix C - Related Documentation/Resources: This section provides readers a list of resources that can be referred to for additional information relating to this system integration.

(14)

About this Manual

Symbols Used

The Notes, Warnings and Cautions used in this manual are listed below.

Note: Contains additional information of interest to the user.

CAUTION or WARNING Type of hazard

How to avoid hazard.

Failure to observe this precaution can result in injury or equipment damage.

DANGER

ELECTRIC SHOCK HAZARD

How to avoid hazard.

Failure to observe these instructions will result in death or serious injury.

(15)

Chapter 1

Introduction and System

Overview

This chapter contains the following topics:

z Description of the Andover Continuum Security and TAC I/A Series security solution

z Purpose of this document

z Common terms and nomenclature used with this solution z Supported device configurations

(16)

Chapter 1: Introduction and System Overview

TAC I/A Series and Andover Continuum Security

Solution

The TAC I/A Series and Andover Continuum Security solution is intended to provide a comprehensive and fully integrated approach to implementing access control functions with the I/A Series of

controllers. Continuum hardware and software components allow security functions to be incorporated into these I/A Series-based systems with minimal extra equipment and software. The I/A Series systems, if used alone, do not normally provide security functionality such as: access control, intrusion detection and digital video

management.

This combined system utilizes I/A Series controllers, such as MNB-1000 or UNC/ENC products, WorkPlace Tech software, Enterprise Servers along with the Schneider Electric Continuum ACX 57xx series controllers enabled with a BACnet/IP XDriver and Continuum

CyberStation to build a complete building management solution.

Purpose of this Document

The main intent of this document is to serve as a reference guide for implementation of an access control system that uses an I/A Series-based control system, exchanging data with a Schneider Electric Continuum ACX 57xx controller with an XDriver and Continuum CyberStation. This guide, along with related documentation, should provide users with sufficient resources to do so.

z The first chapter provides I/A Series users with an overview of the Andover Continuum products and their role in this security solution.

z The subsequent chapters describe the solution and provide instructions for implementing and configuring this solution. More detailed information is located in referenced documentation. z The appendices provide useful reference information that will

(17)

System Architecture

The following diagram shows components that can comprise an Andover Continuum Security and TAC I/A Series security system:

(18)

Key Concepts and Nomenclature

The design of the Andover Continuum Security and TAC I/A Series system is based on several key concepts that related to the software and hardware components of an access control system. These key concepts are described below.

For more thorough descriptions, see the documents referenced in Appendix C.

Access Control System

An access control system is comprised of controllers, software objects, programs, and field devices such as: readers, door strikes, glass-break sensors, and digital video cameras. It controls functions such as: access control, intrusion detection and digital video management.

Network

The network is a medium through which electronic hardware communicates. Andover Continuum products use several types of networks.

Network controllers communicate with a user workstation and with each controller via an Ethernet TCP/IP network. Andover Continuum products support physical wire and fiber versions of the Ethernet as well as wide-area wireless Ethernet.

Andover Continuum

Andover Continuum is system of hardware and software that has been designed to monitor and control the various functions of a building such as security, access control, lighting, and video control. For this specific application, the security and access control capabilities are used. The hardware consists of equipment controllers, network communication controllers, input and output interfaces. The software is a computer

(19)

The values of each point in the system, the settings for limits, the configuration of the hardware, the personal data of the personnel granted access to your building and more are contained within this powerful software structure.

ACX 57xx Series Controller

The ACX 57xx controller is the device that provides direct interface from the I/A Series network to the access control system. The two base models are: 5720 and 5740.

Port

A comm port on a controller is the physical interface from the ACX 57xx controller to another device. The ACX 57xx controller has one ethernet Comm Port connector (COMM1).

CyberStation

One of the key components of the Andover Continuum system is a Windows based application program called CyberStation that runs on a PC workstation and interacts with the control system.

Andover Continuum’s second key software component is the database that stores all the vital information pertaining to the security

management system. ACX Series 5720 5740 Universal Inputs 6 12 Reader Inputs 4 8 Tamper Input 1 1 Digital Outputs 2 4

(20)

CyberStation software provides Continuum with a graphic user interface that can display and manipulate data that allows the entire site management of adjusting schedules, managing video recording, acknowledging alarms, controlling doors, and tracking personnel. CyberStation is the workstation software used to create and configure ACX 57xx controllers, access control features, XDriver objects, and Plain English programs.

Database

The information that describes the structure and operation of your building is stored in a software database. The database engine that Continuum uses is either Microsoft SQL Server or MSDE 2000.

Plain English Programs

Plain English (PE) is Andover Continuum’s proprietary BASIC-like programming language. A Plain English or “PE” program transfers values between the ACX 57xx controller and XDriver objects. These are created in the Plain English editor in CyberStation and are stored in the ACX 57xx controller.

web.Client

web.Client software provides access to the Andover Continuum system via a web browser. However, web.Client’s user interface differs from the Andover Continuum user interface. web.Client is an additional tool that you may use in conjunction with the Continuum Security and TAC I/A Series solution.

Points

The control of equipment requires monitoring individual inputs and actuating individual outputs. These are software objects located in the ACX 57xx controller. In Continuum systems, these discrete entities are

(21)

called points. You’ll see references to “output point” or “input point” often. A point may be classified as one of the following: InfinityInput, InfinityOutput, or InfinityNumeric.

Note: The term “points” may be used interchangeably with “objects” in this solution.

XDriver

XDrivers are gateway software that provides non-native protocol connectivity to third-party devices. In this solution, the XDriver provides communication through BACnet/IP from the I/A Series controllers to the ACX 57xx access controller.

XDriver SelfObject

An XDriver SelfObject is a user-defined object that makes the XDriver device visible to the BACnet/IP network.

XDriver Client Object

This is an XDriver object that reads or writes values to or from other devices on the BACnet/IP network. XDriver Client objects are typically used to update BACnet object values in MNB-1000 or UNC/ENC controllers.

XDriver Server Object

This XDriver object provides read or read/write access from other devices on the BACnet/IP network. XDriver Server objects are typically used to receive BACnet values transmitted from MNB-1000 or UNC/ ENC controllers.

(22)

Door

A door is a software object in the ACX 57xx controller that logically represents the physical characteristics of a Door in a building. This may include access events, alarming and locks.

Door Attributes

Door attributes refer to the individual characteristics of a Door object. Some examples of Door attributes are: Alarm, DoorSwitch, Duress, EntryLastCard, Override, Value, Invalid Attempt, and Forced Entry.

Events

During operation, access control functions occur as a result of actions taken by users, by the controllers, or as the result of no action. This might include the triggering of motion detection or the discovery of a forced door entry. In Continuum systems, these are classified as events. There are several types of events. Each type can be monitored and acted upon through automatic and programmed control. All events are stored by the system.

Alarms

Alarms are a type of event that signal the controller of an unusual occurrence. Typical alarms might include glass break and intrusion attempts.

Schedules

Schedules allow the operation of the system to be regulated according to a particular time, day, week, month, and year.

(23)

User

The user (or operator) is a person who manually acknowledge alarms, monitor system activity, and interact with the system on a regular basis.

Programmer

The programmer is a person who determines the operational flow of the system. The programmer writes programs in the Plain English

(24)

Supported Device Configurations

The following configurations of I/A Series and Andover Continuum devices are supported.

Note: The solid arrow lines signify the data exchange between components of the system.

The dashed arrow lines signify the communication between the ACX 57xx controllers.

Workplace Tech/MNB-1000 Controller/ACX 57xx/CyberStation

In this example, the BACnet/IP XDriver enables communication between the ACX 57xx controller and a MNB-1000 controller. The WorkPlace Tech tool and Cyberstation workstations are used to configure their respective controllers

MNB Controller WorkPlace

(25)

Enterprise Server/UNC/ENC Controller/ACX 57xx/CyberStation

In this example, the BACnet/IP XDriver enables communication between the ACX 57xx controller and a UNC/ENC controller. The WorkPlace Pro and Cyberstation workstations are used to configure their respective controllers.

Enterprise Server/web.Client - 2 machine

In this example, the Enterprise Server views schedules, alarm info, video, etc. via a web browser, while the web.Client-enabled machine holds the database.

UNC Controller Enterprise Server/ WorkPlace Pro ACX 57xx Controller CyberStation Enterprise Server web.Client

(26)

Enterprise Server/web.Client/CyberStation - 3 machine

In this example, the Enterprise server views schedules, alarm info, video, etc. via a web browser, while web.Client accesses the

CyberStation database remotely via a web browser.

Multiple ACX 57xx Controllers

This example shows a several ACX 57xx controllers sharing a single XDriver. The controller hosting the XDriver acts as the

communications gateway between an I/A Series controller and the access control elements in all ACX 57xx controllers.

web.Client CyberStation Enterprise

Server

I/A Series

Controller ACX 57xxController

with BACnet/IP XDriver ACX 57xx Controller ACX 57xx Controller

(27)

Role of XDriver and Plain English in Integration

This section describes the roles of the BACnet/IP XDriver and the Plain English programming language in the integration.

Role of XDriver Points

The BACnet/IP XDriver acts as a gateway between the access control system and MNB-1000 and UNC/ENC controllers. The XDriver and its associated objects are created directly in the ACX 57xx access

controller. It can read or write the values of any of the following BACnet objects: Analog Input, Analog Output, Analog Value, Binary Input, Binary Output, or Binary Value.

XDriver Client objects are typically used to store a predefined access control system value and then transmit the BACnet equivalent of that value to an MNB-1000 or UNC/ENC controller.

XDriver Server objects are typically used to modify an access control system value by receiving the BACnet equivalent of that value from an MNB-1000 or UNC/ENC controller.

For more information about access control system values, refer to Appendix A.

Role of PE Programs

Plain English programs facilitate the transfer of data between XDriver objects and values in the access control system, typically Door

attributes. PE programs are created manually in ACX 57xx controllers with CyberStation software using a predefined language syntax. These programs contain the logic that determines what access control values are shared across the combined system and the interval at which those values are shared. You can customize the number and content of the PE programs used in this system. This allows for maximum system flexibility.

(28)

For more information regarding PE programs, please refer to the

Andover Continuum CyberStation Plain English Language Reference, 30-3001-872.

(29)

Chapter 2

CyberStation

This chapter contains the following topics: z Introduction to CyberStation

z System requirements and pre-installation

(30)

Chapter 2: CyberStation

Introduction

Cyberstation is the application program that allows your workstation PC to configure, monitor and control the Continuum hardware. It is a collection of tools and applications that work together to help you create and interface with all the objects in the system. The figure below illustrates some of them.

(31)

System Requirements and Pre-Installation

This section outlines the basic hardware and software requirements for CyberStation 1.81 software.

Minimum/Recommended Hardware Requirements

The following table shows the minimum and recommended Hardware Requirements for CyberStation version 1.81.

Software Requirements

Depending on the configuration of your system (standalone or multi-user), you must meet a set of software requirements for your workstation PC prior to installing CyberStation. See the software requirements table on the next page.

Hardware Requirements

Minimum Recommended

1.6 GHz Pentium IV processora

a. CyberStation performance is directly related to processor speed and RAM. Faster processor speeds and more RAM available to the program will in-crease performance.

2.4 GHz Pentium IV processor

512 MB RAM 1024 MB RAM

20 GB hard drive 40 GB hard drive CD ROM drive CD ROM drive 10/100 MB Ethernet Network Interface

card

10/100 MB Ethernet Network Interface card

(32)

Software Requirements

Standalone Multi-User (LAN)

Windows XP Professional with Service Pack 2 with Microsoft hotfix 884562

OR:

Windows Server 2003 with Service Pack 1

Internet Explorer 6.0 with Service Pack 1 or

Internet Explorer 7.0 MSDE 2000 (included on the Installation CD and installed automatically) with Service Pack 4 .NET Framework 2.0

AND:

.NET Framework 3.0 (for VideoLayout editor) Windows Installer 3.1 Full Microsoft Outlook or Microsoft Exchange software packagea

a. Required only for emailing or paging alarms and emailing reports.

Workstation:

Windows XP Professional with Service Pack 2 with Microsoft hotfix 884562

OR:

Windows Server 2003 with Service Pack 1

OR:

Windows Server 2003 R2

Internet Explorer 6.0 with Service Pack 1 or Internet Explorer 7.0

NET Framework 2.0 AND:

.NET Framework 3.0 (for VideoLayout editor) Windows Installer 3.1

Full Microsoft Outlook or Exchange software package1

Database Server - OS:

Windows Server 2003, Service Pack 1

OR:

Windows Pro, Service Pack 4

OR:

Windows XP Pro, Service Pack 2 .NET Framework 2.0

Database Server - SQL:

Microsoft SQL Server 2005 or:

(33)

For more detailed information regarding CyberStation installation and system requirements, see: Andover Continuum Cyberstation

Installation Guide, Version 1.81, 30-3001-720.

CAUTION

Database clean up of temporary information

CyberStation requires the SQL Server Agent to be running on standalone workstations and database servers. The purpose of the agent is to perform database clean up of temporary information.

Failure to observe this precaution will result in loss of CyberStation functionality and degraded system performance over a period of time.

(34)

Overview of Common CyberStation Tools and Tasks

This section provides an overview of CyberStation software support tools and tasks in the integrated security solution.

For more detailed instructions regarding these tasks, see the Andover Continuum CyberStation for TAC I/A Series Access Control Essentials Guide, 30-3001-503.

ACX 57xx Controller Update/Configuration

When first implementing the integrated system, CyberStation can be used to update and configure the Comm Port of an ACX 57xx controller when its Comm 1 port has not been enabled for XDriver support. Note: The ACX 57xx controller must have the comm port enabled for

XDriver support. If a controller is purchased that does not have the comm port enabled, you must call the Schneider Electric Repair Dept. at 978-975-7954 to purchase the upgrade option. To update, refer to the instructions regarding enabling the comm port that you receive with the .upd file from the Schneider Electric Repair Department.

XDriver Support

CyberStation is used to install and configure the BACnet/IP XDriver. For more detailed information regarding installing and configuring an XDriver, see Chapter 3 - Using the BACnet/IP XDriver.

Creating Points

One of the main uses of CyberStation in the Andover Continuum Security and TAC I/A Series solution is to create points (also called objects) within the ACX 57xx controllers. The types of points that can be created are: InfinityInputs, InfinityOutputs and InfinityNumerics.

(35)

For details about specifying these configurations, see the “Parameters” section in Chapter 3 - Using the BACnet/IP XDriver.

To create a point

To create a point perform the following steps:

Step 1: In the Continuum Explorer, select the Network or All Paths view.

Step 2: Select the ACX 57xx controller in which you would like to store the new point.

Step 3: Right-click the controller or select New in the Object menu to display a popup list of object classes.

Step 4: Select one of the three applicable object classes: InfinityInput, InfinityOutput or InfinityNumeric.

(36)

For example, select InfinityNumeric to create an InfinityNumeric point object.

Step 5: The New dialog, shown below, appears with the object type you selected displayed in the Objects of type field. In this case, it shows an InfinityNumeric object.

Step 6: In the New dialog, enter a name for the point in the Object name field. CyberStation automatically fills in the Alias field, which you can change.

Note: When creating an XDriver object, it is advised to use 16 or fewer characters for an object name. This allows the object name and alias to remain identical.

Step 7: Click Create to enter the editor of the point you are creating. For more detailed information about creating points and objects, see

Continuum CyberStation Configurator’s Guide, 30-3001-781 or the Continuum online help.

PE Programs

Plain English is a proprietary programming language developed by Schneider Electric. In the Andover Continuum Security and TAC I/A

(37)

transfer of data between the access control system and the XDriver objects. You will use the Plain English IDE in CyberStation to create and edit the programs needed for this task.

For detailed information about Plain English programming, refer to the

Andover Continuum CyberStation Plain English Language Reference, 30-3001-872, or the Continuum online help.

web.Client for Web-based Access

web.Client is an extension of CyberStation used in the system to provide web-based access to most system functions. It is an additional tool that can monitor and control your access control system.

For more specific information regarding web.Client installation and capabilities, see Chapter 4 - web.Client.

(38)

(39)

Chapter 3

Using the BACnet/IP XDriver

This chapter contains the following topics:

z Overview of the BACnet/XDriver security solution z Installation concepts and guidelines for the XDriver z Configuration of the XDriver point parameters z Description of XDriver objects used with this solution z General programming guidelines for the XDriver solution

(40)

Chapter 3: Using the BACnet/IP XDriver

BACnet/IP XDriver Overview

The Schneider Electric BACnet/IP XDriver interface acts as a gateway between a ACX 57xx Controller and BACnet/IP-enabled devices. The gateway, in conjunction with Plain English programs, can present access control values as BACnet values, and provide these values acting either as a client device or a server device.

The user is instructed on how to create the different kinds of XDriver objects that facilitate this functionality in the sections that follow.

BACnet/IP XDriver Requirements

One Schneider Electric ACX 57xx controller, with firmware version 1.000005 or higher is required. Although the XDriver does not

physically use a comm port it does require one to facilitate loading and installation. The option to enable Comm Port 1 can be specified when ordering the ACX 57xx controller.

Note: If a controller is purchased that does not have the comm port enabled, you must call the Schneider Electric Repair Dept. at 978-975-7954 to purchase the upgrade option. The model number and serial number of the ACX 57xx controller will be required. You will receive a update file which should be installed as directed.

Verifying the Controller Options for Installation

To verify that the ACX 57xx is ready for XDriver installation:

Step 1: From Continuum Explorer, double-click the controller where you will be loading the XDriver

OR

Highlight the controller and select “Open” from the File menu.

(41)

Step 3: Verify that the Comm Port 1 is bit value 9 (hex). If the bit value of “Xdriver Comm 1”is 9, then the comm port is ready for installation of the BACnet/IP XDriver.

Note: The item in parenthesis after the bit value in the “Xdriver Comm” field is the checksum appropriate to that version of the XDriver.

BACnet/IP XDriver Installation

Note: Only one BACnet/IP XDriver can be installed per controller. The BACnet/IP XDriver software is loaded via the comm port, as follows:

(42)

Step 1: Click the controller or click on the + sign next to the controller icon to display its contents in the viewing pane.

Step 2: Double-click on the “COMM1” object under the controller. Step 3: From the General tab, select “Xdriver” from the Default

Mode dropdown menu.

Step 4: Click on the “Browse” button in the XDriver File Name field. Note: XDriver files commonly use the extension “.xdr”.

(43)

Step 6: Click the “OK” button to close the Comm Port editor.

Step 7: Right-click on the controller from step 1 and select “Send To Controller” to reload the controller.

Step 8: Once the controller is reloaded, open the Comm Port editor for Comm1.

Step 9: Click the “XDriver Status” button to confirm that it was properly installed on the controller.

Step 10: The XDriver details window should respond with the status indicating “Xdrvinstalled”, which means the XDriver is loaded and ready for use. See below:

Configuration

Overview

The BACnet I/P Xdriver allows the creation of three types of points: Client XDriver point, Server XDriver point, and a DeviceSelf Object. The Client XDriver point is a point that polls and/or writes new values to an object that resides in another BACnet device.

(44)

Server XDriver points operate in a passive mode. They give other BACnet devices visibility and control over their points. Server XDriver points include a security option that can be set to read-only or read/ write access.

The DeviceSelf Object is a required object for the BACnet/I/P XDriver. There must be only one DeviceSelf Object per BACnet XDriver. Its function is to specify operating parameters for the XDriver. A DeviceSelf Object MUST be created to enable communication, and to start the driver.

Although the XDriver can contain both Client and Server objects, the XDriver operates most efficiently as a BACnet client, especially when large amounts of data are transferred between the access control system and the BACnet/IP network. As such, the user is advised to utilize Client objects to distribute access control values whenever possible. Server objects are used only when an access control value must be adjusted from outside the access control system.

Parameters

InfinityInput, InifintyOutput and InfinityNumeric points created in CyberStation must be configured with specific parameter values when used as XDriver objects. After the comm port is enabled and the BACnet/IP XDriver is installed, new points should be configured with the following values.

To configure these points:

Step 1: Double-click on the point that you would like to configure to open the corresponding object editor.

To create an entirely new Infinity point, see the “To Create a Point” section in Chapter 2 - Cyberstation.

(45)

Step 2: Six additional fields appear below the "Port" field. They are "Point Access", "Type", "Instance", "Property", "BACnet Network" and "IP Address".

Step 3: See below for the values required for each parameter field.

Point Access

From the table below:

1. Select the appropriate Point Access type. 2. Enter the value into the “Point Access” field. 3. Press TAB.

Value Access Type Description

0 Client or Self The point will poll and/or

write as a Client XDriver Point

1 Server Read Only BACnet can ONLY read this

point.

2 Server Read/Write BACnet can read and write to

(46)

Type

From the table below:

1. Select the appropriate Object Type.

XDriver Client object: the type matches the BACnet object type of the

remote object that it is referencing.

XDriver Server object: the type determines the BACnet object type of

the internal XDriver Server object.

2. Enter the value into the “Type” field. 3. Press TAB.

Instance

This field accepts a number from 1 to 65,535. Value Object Type

0 Analog Input 1 Analog Output 2 Analog Value 3 Binary Input 4 Binary Output 5 Binary Value

(47)

If an Instance number > 65535 is required, then set the Instance Number to 0 and add the number to the end of the I/P address. The Instance number must be prefixed with a capital I (i.e. xxx:xxx:xxx:xxx Iyyyyyy where xxx is the IP address and yyyyyy is the Instance number).

Property

For Client or Server points, the value should always be 85 (Present Value).

(48)

BACnet Network

1. Enter the BACnet/IP network number that this XDriver is connected to.

2. Press TAB.

IP Address

If this point is a Client XDriver point, then this field must contain the TCP/IP address of the other BACnet device, using the format:

XXX.XXX.XXX.XXX Optional Parameters

The additional optional parameters referenced below are allowed in this “IP Address” field. These options must be added after the TCP/IP address, if one is used, and require a <space> character between each parameter.

Instance Number

If an instance number > 65535 is required then set the instance number to 0 and add the number to the end of the TCP/IP address. the instance number must be prefixed with a capital I as shown below:

XXX.XXX.XXX.XXX IYYYYYY

where XXX is the IP address and YYYYYY is the instance number. Engineering Units

If the point or object is configured as a BACnet Server point or object, the engineering units for each point may be assigned using this field. The units are defined by entering ‘U’ followed by the enumerated value from the Engineering Units conversion table.

(49)

Priority

The present value of Analog Output, Analog Value, Binary Output, and Binary Value points or objects can be read or written with a priority level. Different priority levels may be assigned to individual points by assigning the priority parameter to each XDriver point.

For both Client and Server objects, if no Priority is assigned the XDriver uses priority 10 when reading or writing the present value. If a Priority is assigned to the DeviceSelf object then the XDriver uses that priority level as its default priority level.

To clear the value from the priority array set the XDriver point to ‘NotSet’. This will clear the appropriate value (determined by the priority level of this point) from the priority array.

The following sample parameter would assign priority level 6 when the value of the point/object is modified:

P6

Relinquish Default

For Server objects only: When all 16 entries in the priority array are empty the value of the commandable property shall have the value specified by the relinquish default property. This determines the server object’s value when present value has been written at no priority. The example below would set the Relinquish Default value to 100: R100

(50)

For Client XDriver objects only: This optional parameter is used to communicate through BACnet routers, so that messages can be relayed from the BACnet/IP network to another. (i.e. MS/TP or ISO 8802-3 ‘Ethernet’). The destination address is used in conjunction with the BACnet network number (Param5) to address messages to devices on other networks.

The Destination address (DADR) must be denoted as follows: DADR=<BACnet MAC Address>

Examples for an MS/TP network would be (specified in decimal notation).

DADR=1 DADR=19

Examples for an ISO 8802-3 (‘Ethernet’) would be: DADR=00:0B:DB:A2:A0:15

DADR=00:40:11:3C:4F:22

Note: The Destination address must be in capital letters with equals ‘=’ sign and no spaces.

BACnet/IP Port

By default the XDriver uses UDP port 0xBAC0. This may be changed by adding the following command ‘PORT=’ to the BACnet DeviceSelf object.

PORT=BAC1

Note: The BACnet UDP port address must be in capital letters with equals ‘=’ sign and no spaces. The address must be represented in hexadecimal format and may only be added to the BACnet DeviceSelf object.

(51)

BACnet XDriver Points Overview

This section describes and provides many examples of BACnet XDriver points.

Note: The term “points” may be used interchangeably with “objects” in this solution.

Client BACnet XDriver Points

Client points poll and/or write new values to points in other BACnet devices. Client points are not visible to other BACnet devices.

If a point is created as an Infinity INPUT, then its function is to poll an object for its current value. If a point is created as an Infinity OUTPUT, it writes a new value to the Present Value property of the remote object only if its value has changed. If a point is created as an Infinity NUMERIC, it polls and writes as specified above.

z When a Client object is created, you must set the Point Access parameter to 0.

z The Type parameter is set to match the kind of object the Client object is referencing on the other BACnet device.

z The Instance Number is set to match the instance number of the object that the Client references.

z The Type and Instance Number must be unique for each Client point.

z The IP Address is set to the TCP/IP address of the host BACnet device.

(52)

Examples of a Client BACnet XDriver Point

Example 1

Client BACnet point

z Point Access = 0 (Client BACnet XDriver Point) z Type = 1 (Analog Output)

z Instance = 4 ( Instance is 4) z Property = 85 (Present Value)

z BACnet Network = 1 (BACnet network number is 1)

z IP Address = 172.16.83.24 = (TCP/IP Address of other device) Note: If an Instance number > 65535 is required the Instance field

should be set to 0 and the Instance number appended to the end of the IP address with a <space> Iyyyyyy separating the 2 parameters.

(53)

Example 2

Client BACnet point with Priority Level

z Point Access = 0 (Client BACnet XDriver Point) z Type = 4 (Binary Output)

z Instance = 1 (Instance is 1) z Property = 85 (Present Value)

z BACnet Network = 1 (BACnet network number is 1)

z IP Address = 172.16.83.99 = (TCP/IP Address of other device)

(54)

Example 3

Client BACnet XDriver point with network addressing (MS/TP device)

z Point Access = 0 (Client BACnet XDriver Point) z Type = 0 (Analog Input)

z BACnet Network = 2765 (BACnet network number is remote) z IP Address = 172.16.83.4 DADR=1

(55)

Server BACnet Points

Server BACnet points allow other BACnet devices access to ACX 57xx controller objects. These must be set up with either Read or Read/Write access. Because Server objects are visible to other devices as BACnet objects, any BACnet device can read their properties.

z When a Server object is created, you must specify the Point Access (1 or 2).

z The Type field is set to match the kind of object you are creating. z The Instance is a number with a unique value in the range of 1 -

65535. Care should be taken when choosing values for BACnet objects. You should ensure that no two objects have the same type/ instance combination.

z The IP Address field is left blank unless optional parameters are required:

Engineering units have to be prefixed with the letter ‘U’ followed by

their corresponding numeric value.

Priority levels are prefixed with the letter ‘P’.

(56)

Example 1

Server BACnet Point

z Point Access = 2 (Read/Write BACnet Server Point) z Type = 2 (Analog Value)

z BACnet Network = 1 (BACnet network number is 1) z IP Address = <blank> (Not Required)

(57)

Example 2

Server BACnet Point with Engineering Units

z Point Access = 2 (Read/Write BACnet Server Point) z Type = 2 (Analog Value)

z BACnet Network = 1 (BACnet network number is 1) z IP Address =

(58)

Example 3

Server BACnet Point with Engineering Units, Relinquish Default, and

Priority Level

z Point Access = 2 (Read/Write BACnet Point BACnet Server) z Type = 2 (Analog Value)

z Instance = 1 (Device Instance) z Property = 85 (value)

z BACnet Network = 1 (BACnet network number is 1) z IP Address =

Units = Percent

Relinquish Default value = 50 Priority Level = 5

(59)

DeviceSelf Object

There can be only one DeviceSelf object per BACnet/IP XDriver. The DeviceSelf object is an InfinityNumeric and is required to enable the BACnet XDriver. Its function is to configure the XDriver’s run-time parameters.

z The Point Access must be set to Read/Write (2). The DeviceSelf object must be accessible via BACnet for remote devices to query driver information.

z The Type must be set to 200 to specify this is the Device Self Object.

z The Instance should be set to a unique value between 1 - 65535. This number must be unique among all the BACnet devices participating in the entire BACnet internetwork.

z For the DeviceSelf object, the Property is used as a tuning

variable called Service Limit. The Service Limit parameter specifies the number of BACnet/IP packets to send per second. If it is set to 25 and there are less than 26 packets to be sent then all of the packets will be sent for each second. If there are more than 25 to be sent for each second then the BACnet/IP XDriver will send up to 25, then wait for one second before continuing to send the remainder of the point values. Valid values are 1 – 25.

z BACnet Network is used to specify the BACnet network number that this XDriver is connected to. The range is 1 – 65534. The default is 0.

z The IP Address field is only used to change the default priority level and/or the BACnet/IP UDP Port address.

(60)

Example 1

DeviceSelf Object

z Point Access = 2 (2 is required for DeviceSelf Object) z Type = 200 (200 is required for DeviceSelf Object) z Instance = 99 (Device SelfObject unique Instance is 99) z Property = 25 (Tuning variable: 25 points per second) z BACnet Network = 1 (BACnet network number is 1) z IP Address = <Blank> (Not Required)

(61)

Example 2

DeviceSelf Object with a specific UDP port address

z Point Access = 2 (2 is required for DeviceSelf Object) z Type = 200 (200 is required for DeviceSelf Object) z Instance = 62 (DeviceSelf Object unique Instance is 62) z Property = 25 (Tuning variable: 25 points per second) z BACnet Network = 1 (BACnet network number is 1)

z IP Address = PORT=BAC1

This would set the BACnet UDP port to 0xBAC1, by default the UDP port is set to 0xBAC0.

(62)

Example 3

DeviceSelf Object with default Priority Level

z Point Access = 2 (2 is required for DeviceSelf Object) z Type = 200 (200 is required for DeviceSelf Object) z Instance = 99 (Device Self Object unique Instance is 99) z Property = 25 (Tuning variable: 25 points per second) z BACnet Network = 1 (BACnet network number is 1) z IP Address = <Blank> (Not Required)

(63)

Priority Levels and Relinquish default

z If no priority levels are assigned the XDriver uses priority level 10 for all commandable objects (Analog Output, Analog Value, Binary Output, Binary Value)

z If no priority level is assigned to the DeviceSelf object the XDriver uses this priority as its default priority level.

z If a priority level is assigned to any XDriver Server point then that priority level is used when that point is commanded.

z When all entries in the priority array are empty the value of the commandable property shall have the value specified by the relinquish default property.

(64)

Programming Introduction

This section describes Schneider Electric proprietary Plain English(PE) programming language, and provides many programming examples.

Plain English Programming Language

The Andover Continuum Security and TAC I/A Series solution uses a proprietary programming language called Plain English(PE).

Programming in Plain English consists of simple Plain English words, known as keywords, that are arranged in a predefined structure. You can easily write programs that perform very complex control system decisions. The Plain English Integrated Development Environment (IDE) is a set of highly integrated programming tools that allows you to write and edit Plain English programs. Plain English programs are the mechanisms that transfer information between the XDriver BACnet/IP gateway and ACX 57xx access controllers.

For more detailed information about Plain English programs and Plain English programming, please refer to the Andover Continuum Plain English Language Reference, 30-3001-872, or to the Continuum Integrated Help System.

Programming Examples - Single ACX 57xx Controller

This section provides tips and code examples for creating and using Plain English programs to facilitate certain tasks, such as distributing persistent and non-persistent access control values and changing access control values from MNB-1000 or UNC/ENC controllers. The sample programs in this section are appropriate when a single ACX controller with an XDriver is used. Please see the examples in the section, "Programming Examples – Multiple ACX 57xx Controllers", in the following section for sample programs appropriate for use with multiple ACX controllers and a single XDriver.

(65)

The examples in this section correspond to the table in Appendix A -

“Supported Access Control Elements". Please refer to this appendix to view the different access control elements which Plain English programs may reference.

Note: The program type for each example corresponds to the “Program Type” field in Appendix A.

Program Type 1

Distribute Door Attribute Values to MNB-1000 or UNC/ENC Controllers

When a Persistent Door Attribute Changes

In our first sample program we show how to distribute a Door attribute value to an MNB-1000 or UNC/ENC controller whenever the value of that attribute changes. In this case we distribute the value of, "State", which indicates whether or not the door is currently enabled.

For the purposes of this example it is assumed that the user has previously created an XDriver Client object named, " XdrvrClientObj" that updates an object in and MNB-1000 or UNC/ENC controller each time the value of XdrvrClientObj changes. Since the range of values for the attribute “State” is limited to 0 or 1, the BACnet object type of the associated MNB-1000 or UNC/ENC controller object could be either Analog or Binary.

Note: This program and all other sample programs in this section should be configured as Looping and Autostart.

Program Type 1

Numeric nState Line 1

nState = Door1 State XdrvrClientObj = nState Goto 2

(66)

If nState <> Door1 State Then nState = Door1 State XdrvrClientObj = nState EndIf

Line E Goto 1

The first thing to notice is that we defined the variable, "nState", in the variable declaration section, prior to Line 1. This variable is then used in Line 1 to store the current State value (typically this value is True or 1, meaning "Enabled"). The program then assigns value of nState to, "XdrvrClientObj", which in turn updates the value of the associated MNB-1000 or UNC/ENC object.

Once directed to Line 2, further program execution will occur only when State differs from nState (typically when the value changes to False or 0, meaning "Disabled"), by including in the line, "If nState <> Door1 State Then".

When this condition is met, the program will execute the two lines inside the If/End If clause. The first of these statements, "nState = Door1 State" initializes the variable with the new State value, while the following statement, " XdrvrClientObj = nState" again causes the X-Driver Client object to distribute the most recent value.

Note: Because Line 2 does not contain a "GoTo" statement the program will remain in Line 2, waiting for the next change of value, until the controller restarts or a run-time error occurs. If a run-time error occurs, the program will automatically disable unless the program includes a line label at the end of the program, "Line E". You will notice that the current program's Line E contains a single GoTo statement that directs program execution back to Line 1. This will cause the program to attempt to distribute the most recent State value whenever communication with the second device is restored. We recommend that you include a Line E in all of your programs.

(67)

Note: The most common cause of a run-time error is when a remote device with which the program attempts to communicate cannot be contacted.

Program Type 2

Modify Door Attribute Values from MNB-1000 or UNC/ENC Controllers

In the second sample program we examine how to modify a Door attribute value by setting the attribute equal to the value of an XDriver Server object that an MNB-1000 or UNC/ENC controller modifies. In this case we change the PermanentUnlock attribute, which indicates whether the door is indefinitely unlocked. The door is not indefinitely unlocked when PermanentUnlock is False or 0 (the default value), and is indefinitely unlocked when PermanentUnlock is True or 1. For the purposes of this example it is assumed that the user has previously created an XDriver Server object named, "XdrvrSrvrObj ", using the BinaryValue BACnet object type.

Program Type 2

Numeric nCurrentValue Line 1

nCurrentValue = XdrvrSrvrObj

Door1 PermanentUnlock = nCurrentValue Goto 2

Line 2

If nCurrentValue <> XdrvrSrvrObj Then Goto 1 Line E

Goto 1

As we did in the first sample program we have declared a single program variable prior to Line 1, this time named, "nCurrentValue". In this program nCurrentValue will temporarily store the value of

(68)

XdrvrSrvrObj whenever the program starts or the value of

XdrvrSrvrObj changes. The PermanentUnlock attribute is then set equal to the variable's value.

Notice that in Line 1 nCurrentValue first receives the value of XDriver Server object when the statement, "nCurrentValue = XdrvrSrvrObj" executes.

This value is then assigned to PermanentUnlock at the next statement, "Door1 PermanentUnlock = nCurrentValue". Once directed to Line 2 the program compares the values of nCurrentValue and XdrvrSrvrObj and returns to Line 1 only when those values differ, using the

statement, "If nCurrentValue <> XdrvrSrvrObj Then Goto 1". Once in Line 2 these values should differ only when a MNB-1000 or UNC/ENC device changes the value of XdrvrSrvrObj.

Program Type 3

When a One-Scan Door Attribute Changes

Our final example deals with distributing values when a one-scan attribute changes. As previously mentioned, a one-scan value deviates from its default value for only a single controller scan and is therefore available only within the first execution of the program's current line label.

Program Type 3

Line 1

If Door1 ValidAccess = TRUE then

XdrvrClientObj1 = Door1 EntryLastCard XDrvrClientObj2 = Door1 EntryLastSite XdrvrClientObj3 = Door1 EntryCount EndIf

Line E Goto 1

(69)

In this sample program we update several XDriver Client objects each time the door attribute, "ValidAccess" becomes True. For the purposes of this example it is assumed the user has created three XDriver Client objects, "EntryLastCard", "EntryLastSite", and "EntryCount", each of which updates a different MNB-1000 or UNC/ENC object value. Since the range of values for these attributes is not limited to 0 or 1, the BACnet object type of the corresponding MNB-1000 or UNC/ENC controller objects should be Analog (Output or Value).

Note: The program execution will remain in Line 1 unless an error occurs.

You will notice that this program uses no program variables and instead directly updates the XDriver Client objects each time ValidAccess is True, indicating that the door has received a valid request to unlock (typically this occurs when a cardholder presents a valid card at the door's electronic reader). Also, ValidAccess is always False except for the controller scan coinciding with a valid access event.

Programming Examples – Multiple ACX 57xx Controllers

This section expands upon the code examples from the previous section by demonstrating how to use Plain English programs to perform analogous tasks when using multiple ACX 57xx controllers with a single XDriver. Since the application logic of the programs that follow is identical to the programs from those previously illustrated, we draw the user's attention only to the concepts that apply to programs that share information among multiple ACX 57xx controllers.

The code examples that follow assume an environment with two ACX 57xx controllers, "FirstACX" and "SecondACX", and the environment's single XDriver is contained in FirstACX.

(70)

Program Type 1

Distribute Door Attribute Values to MNB-1000 or UNC/ENC Controllers

when a Persistent Door Attribute Changes in the SecondACX

For the purposes of this example it is assumed that the user has previously created an XDriver Client object named, "XdrvrClientObj" in FirstACX that updates an object in an MNB-1000 or UNC/ENC controller each time the value of XdrvrClientObj changes.

This program should be created in SecondACX. Program Type 1

Numeric nState Line 1

nState = Door1 State

FirstACX\XdrvrClientObj = nState Goto 2

Line 2

If nState <> Door1 State Then nState = Door1 State

FirstACX\XdrvrClientObj = nState EndIf

Line E Goto 1

Similar to the first example from the previous section, we again update the value of the pre-configured Client XDriver point, XdrvrClientObj. In this case, however, since the XdrvrClientObj is contained in

FirstACX and this program in SecondACX, the program must reference XdrvrClientObj using remote object reference syntax.

(71)

Notice that the name of FirstACX precedes the name of the Client XDriver point, and those names are separated by a backslash ("\"). The value we wish to transmit is then assigned directly to XdrvrClientObj in Lines 1 and 2.

Program Type 2

Modify Door Attribute Values in SecondACX from MNB-1000 or UNC/ENC

Controllers

In the second sample program we show how to modify a Door attribute value in SecondACX by setting the attribute equal to the value of an XDriver Server object from FirstACX.

For the purposes of this example it is assumed that the user has previously created an XDriver Server object named, "XdrvrSrvrObj" in FirstACX, using the BinaryValue BACnet object type.

This program should be created in FirstACX. Program Type 2

Numeric nCurrentValue Line 1

nCurrentValue = XdrvrSrvrObj

SecondACX\Door1 PermanentUnlock = nCurrentValue Goto 2

Line 2

If nCurrentValue <> XdrvrSrvrObj Then Goto 1 Line E

Similar to the second example from the previous section, we again update the value of pre-configured Server XDriver point, XdrvrSrvrObj. Since XdrvrSrvrObj and this program are contained in FirstACX and the target Door object in SecondACX, the program must again use remote object reference syntax, as shown in Line 1.

(72)

Program Type 3

When a One-Scan Door Attribute Changes in SecondACX

In our final example, we show how to distribute one-scan values in a multiple ACX 57xx controller environment.

For the purposes of this program it is assumed that FirstACX has the Client XDriver objects, " XdrvrClientObj1", " XdrvrClientObj2", and " XdrvrClientObj3".

This program should be created in SecondACX. Program Type 3

Line 1

If Door1 ValidAccess = TRUE then

FirstACX\XdrvrClientObj1 = Door1 EntryLastCard FirstACX\XDrvrClientObj2 = Door1 EntryLastSite FirstACX\XdrvrClientObj3 = Door1 EntryCount EndIf

Line E Goto 1

Notice once again that Client objects in FirstACX are referenced using the remote object reference syntax, and that the appropriate values are transmitted whenever the one-scan value changes.

(73)

Chapter 4

web.Client

This chapter contains the following topics: z Introduction to the web.Client tool

z System and Pre-Installation Requirements z web.Client Setup Configurations

z Hardware and Software Requirements for LAN System

z Hardware and Software Requirements for a Standalone System z web.Client User Documentation

Note: Before installing or upgrading to web.Client version 1.81, be sure the requirements outlined in this chapter are satisfied.

web.Client users must have a password to log on.

web.Client user names and passwords are the same as Continuum user names and passwords.

(74)

Chapter 4: web.Client

web.Client Overview

web.Client is an application that can provide you with web-enabled access to your access control system. By using a standard browser, your authorized personnel can access the access control system in real time across your site’s local area network (LAN) or across your wide-area network (WAN).

web.Client is either added to a LAN Continuum CyberStation system or installed with a standalone CyberStation on a single PC. The web.Client application can be accessed via a web browser on an Enterprise Server/WorkPlace Pro machine for use with this Andover Continuum Security and TAC I/A series solution.

With the basic web.Client Personnel Manager option, you can: z Create, search for, edit, and delete personnel records z Change employee access privileges

z View a person’s access events

z View and generate reports of all access events, including area access events, access events by persons, and distribution-event transactions via the Access Distribution View

z Edit and view schedules and calendars. z Change a password.

With the advanced web.Client Pro option, you have all the features of the basic web.Client Personnel Manager option as well as the following additional features:

z Create, run, and view graphical reports (class object Report), including bar charts, pie charts, trend charts, text reports, and so on.

z List and view graphics and groups z View live system alarms and live events

z View live video, as well as search for and view recorded video, via the class object, VideoLayout.

(75)

z Search for web.Client objects by exploring a folder tree hierarchy or a network/device tree hierarchy, or by using a text search engine.

web.Client User Documentation

This section lists related user documentation for web.Client.

Extensive online help is available within the web.Client application browser window. To view the help topics for web.Client, click the question mark button that appears at the top of every web.Client screen. The online help covers all of the major features in the web.Client user interface.

.

A Typical System before web.Client

The following illustration shows how your Andover Continuum system is used before web.Client:

An integrated system without web.Client consists of a database server and high powered, dedicated workstations connected via the TCP/IP network. Also note that all administration must be performed at one of the dedicated workstations.

The following illustration shows the administration of the typical system would entail. In this security example, a single administrator is responsible for assigning all security privileges for engineering and manufacturing personnel.

(77)

A Typical System Implementing web.Client

Illustrations on the next page show how your system is utilized when web.Client is added to an integrated system. As shown in the second illustration, a web.Client local area network (LAN) system consists of: z A database server

z Dedicated workstations for configuration z A dedicated web.Client application server

z PCs running Internet Explorer 6.0 or 7.0 connecting web.Client

You can delegate security tasks to authorized personnel who then assign security privileges for their departments (in this case, engineering and manufacturing personnel).

You use the dedicated workstati