Andover Continuum Tac Ia Data Exchange Reference Guide

Andover Continuum Security andTAC I/A Series

Data Exchange Reference Guide

© 2010, Schneider Electric

All Rights Reserved

No part of this publication may be reproduced, read or stored in a retrieval system, ortransmitted, 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 areowned 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. Forservice, 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 subjectto 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 appearin this document.

Schneider ElectricOne High StreetNorth Andover, MA 01845(978) 975-9600Fax: (978) 975-9782http://www.schneider-electric.com/buildings

Andover Continuum Security and TACI/A Series Data Exchange Reference Guide

30-3001-406Revision B

December, 2010

Contents

Standard Regulatory Notices for Andover Continuum Hardware5

Federal Communications Commission ...................................... 5Industry Canada ......................................................................... 5CE - Compliance to European Union (EU) ................................ 5Australian Communications Authority (ACA) .......................... 6WEEE - Directive of the European Union (EU) ........................ 6RoHS - Restriction of Hazardous Materials .............................. 6UL Listing .................................................................................... 6

About this Manual ................................................................. 9What’s in this Manual ................................................................. 9Symbols Used .............................................................................. 10

Chapter 1 Introduction and System Overview .................................... 11TAC I/A Series and Andover Continuum Security Solution ..... 12Purpose of this Document ........................................................... 12System Architecture .................................................................... 13Key Concepts and Nomenclature ............................................... 14

Access Control System ....................................................... 14Network .............................................................................. 14Andover Continuum ........................................................... 14ACX 57xx Series Controller ............................................... 15Port ..................................................................................... 15CyberStation ....................................................................... 15Database ............................................................................. 16Plain English Programs ..................................................... 16web.Client ........................................................................... 16Points .................................................................................. 16XDriver ............................................................................... 17

Andover Continuum CyberStation Access Control Essentials Guide 1

XDriver SelfObject ............................................................. 17XDriver Client Object ........................................................ 17XDriver Server Object ....................................................... 17Door ..................................................................................... 18Door Attributes .................................................................. 18Events ................................................................................. 18Alarms ................................................................................ 18Schedules ............................................................................ 18User ..................................................................................... 19Programmer ....................................................................... 19

Supported Device Configurations .............................................. 20Workplace Tech/MNB-1000 Controller/ACX 57xx/CyberStation 20Enterprise Server/UNC/ENC Controller/ACX 57xx/CyberSta-tion ...................................................................................... 21Enterprise Server/web.Client - 2 machine ........................ 21Enterprise Server/web.Client/CyberStation - 3 machine 22Multiple ACX 57xx Controllers ......................................... 22

Role of XDriver and Plain English in Integration ..................... 23Role of XDriver Points ....................................................... 23Role of PE Programs .......................................................... 23

Chapter 2 CyberStation ......................................................................... 25Introduction ................................................................................. 26System Requirements and Pre-Installation .............................. 27

Minimum/Recommended Hardware Requirements ......... 27Software Requirements ..................................................... 27

Overview of Common CyberStation Tools and Tasks ............... 30ACX 57xx Controller Update/Configuration .................... 30XDriver Support ................................................................. 30Creating Points .................................................................. 30

To create a point .......................................................... 31PE Programs ...................................................................... 32web.Client for Web-based Access ...................................... 33

Chapter 3 Using the BACnet/IP XDriver ............................................... 35BACnet/IP XDriver Overview .................................................... 36

BACnet/IP XDriver Requirements .................................... 36Verifying the Controller Options for Installation ...... 36

2 Schneider Electric

BACnet/IP XDriver Installation ........................................ 37Configuration ............................................................................... 39

Overview ............................................................................. 39Parameters ......................................................................... 40

Point Access ................................................................. 41Type .............................................................................. 42Instance ........................................................................ 42 ...................................................................................... 43Property ........................................................................ 43BACnet Network .......................................................... 44IP Address .................................................................... 44

BACnet XDriver Points Overview .............................................. 47Client BACnet XDriver Points .......................................... 47

Examples of a Client BACnet XDriver Point ............. 48Server BACnet Points ........................................................ 51

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

..............................................................................................DeviceS-elf Object ............................................................................. 55

Programming Introduction ......................................................... 60Plain English Programming Language ............................ 60Programming Examples - Single ACX 57xx Controller ... 60

Program Type 1Distribute Door Attribute Values to MNB-1000 or UNC/ENC Controllers When a Persistent Door Attribute Changes .......................................................................................61Program Type 2Modify Door Attribute Values from MNB-1000 or UNC/ENC Controllers ................................................................... 63Program Type 3Distribute Door Attribute Values to MNB-1000 or UNC/ENC Controllers When a One-Scan Door Attribute Changes 64

Programming Examples – Multiple ACX 57xx Controllers 65Program Type 1 ........................................................... 66Distribute Door Attribute Values to MNB-1000 or UNC/

Andover Continuum CyberStation Access Control Essentials Guide 3

ENC Controllers when a Persistent Door Attribute Changes in the SecondACX ........................................................ 66Program Type 2Modify Door Attribute Values in SecondACX from MNB-1000 or UNC/ENC Controllers ................................... 67Program Type 3Distribute Door Attribute Values to MNB-1000 or UNC/ENC Controllers When a One-Scan Door Attribute Changes in SecondACX .............................................................. 68

Chapter 4 web.Client .............................................................................. 69web.Client Overview ................................................................... 70web.Client User Documentation ................................................ 71A Typical System before web.Client .......................................... 72A Typical System Implementing web.Client ............................. 73Differences between web.Client and CyberStation ................... 75Hardware and Software Requirements for LAN System ......... 76Hardware and Software Requirements for a Standalone System 79

Appendix A Supported AccessControl Elements .................................................................. 83

Appendix B Best Practices ....................................................................... 91Tips for Successful Implementation ........................................... 92

Appendix C Related Documentsand Resources ...................................................................... 95


Regulatory Notices

Standard Regulatory Noticesfor Andover Continuum

Hardware

Federal Communications Commission

FCC Rules and Regulations CFR 47, Part 15, Class A

This device complies with part 15 of the FCC Rules. Operation is subject to the following two conditions: (1) This device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesired operation.

Caution: the user that changes or makes modifications not expressly approved by Schneider Electric for compliance could void the user's authority to operate the equipment.

Industry Canada

ICES-003This 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 directive 2004/108/EEC governing the Self Declaration of the CE Marking for the European Union.

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

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


Regulatory Notices

CAUTIONAll 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.


Regulatory Notices


About this Manual

About this Manual

What’s in this Manual

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.Chapter Two - CyberStation: This chapter focuses on the Continuum CyberStation software that is used to perform certain functions within the security solution.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.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.Appendix A - Supported Access Control Elements: This appendix is a spreadsheet view of the devices and attributes supported by this security solution.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.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.


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 WARNINGType of hazardHow to avoid hazard.

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

DANGERELECTRIC SHOCK HAZARDHow to avoid hazard.

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


Chapter 1Introduction and System

Overview

This chapter contains the following topics:

Description of the Andover Continuum Security and TAC I/A Series security solutionPurpose of this documentCommon terms and nomenclature used with this solutionSupported device configurationsRoles of XDriver points and PE Programs


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.

The first chapter provides I/A Series users with an overview of the Andover Continuum products and their role in this security solution. The subsequent chapters describe the solution and provide instructions for implementing and configuring this solution. More detailed information is located in referenced documentation.The appendices provide useful reference information that will assist in the implementation of the solution.



System Architecture

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



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 program that allows you to communicate with, monitor and control the operation of the system.



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



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



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.



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.



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 programming language.



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

MNBController

WorkPlaceTech

ACX 57xxController

CyberStation



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.

UNCController

EnterpriseServer/WorkPlacePro

ACX 57xxController

CyberStation

EnterpriseServer

web.Client



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 CyberStationEnterpriseServer

I/A SeriesController

ACX 57xxControllerwithBACnet/IPXDriver

ACX 57xxController

ACX 57xxController



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.



For more information regarding PE programs, please refer to the Andover Continuum CyberStation Plain English Language Reference, 30-3001-872.


Chapter 2CyberStation


Introduction to CyberStationSystem requirements and pre-installation Overview of common CyberStation tools and tasks


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.



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 RequirementsMinimum 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 RAM20 GB hard drive 40 GB hard driveCD ROM drive CD ROM drive10/100 MB Ethernet Network Interface card

10/100 MB Ethernet Network Interface card

Parallel or USB port Parallel or USB port



Software RequirementsStandalone 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.0AND:

.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 orInternet Explorer 7.0

NET Framework 2.0AND:

.NET Framework 3.0 (for VideoLayout editor)

Windows Installer 3.1Full 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:Microsoft SQL Server 2000 with Service Pack 4



For more detailed information regarding CyberStation installation and system requirements, see: Andover Continuum Cyberstation Installation Guide, Version 1.81, 30-3001-720.

CAUTIONDatabase clean up of temporary informationCyberStation 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.



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. These points will later be configured as XDriver objects.



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.



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 Series system, Plain English programs are used to facilitate the



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.




Chapter 3Using the BACnet/IP XDriver


Overview of the BACnet/XDriver security solutionInstallation concepts and guidelines for the XDriverConfiguration of the XDriver point parametersDescription of XDriver objects used with this solutionGeneral programming guidelines for the XDriver solution


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.

Step 2: When the controller editor window appears, click the Options tab.



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:



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”.

Step 5: Select the XDriver file on the server or workstation.



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.



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.



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 this point.



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



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).



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.

The example below would correspond to Pascal:

U53



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

Destination Address



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.



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.

When a Client object is created, you must set the Point Access parameter to 0. The Type parameter is set to match the kind of object the Client object is referencing on the other BACnet device.The Instance Number is set to match the instance number of the object that the Client references. The Type and Instance Number must be unique for each Client point.The IP Address is set to the TCP/IP address of the host BACnet device.



Examples of a Client BACnet XDriver Point

Example 1Client BACnet point

Point Access = 0 (Client BACnet XDriver Point)Type = 1 (Analog Output)Instance = 4 ( Instance is 4)Property = 85 (Present Value)BACnet Network = 1 (BACnet network number is 1)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.



Example 2Client BACnet point with Priority Level

Point Access = 0 (Client BACnet XDriver Point)Type = 4 (Binary Output)Instance = 1 (Instance is 1)Property = 85 (Present Value)BACnet Network = 1 (BACnet network number is 1)IP Address = 172.16.83.99 = (TCP/IP Address of other device)

Priority Level = 8



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

Point Access = 0 (Client BACnet XDriver Point)Type = 0 (Analog Input)Instance = 3 (Instance is 3)Property = 85 (Present Value)BACnet Network = 2765 (BACnet network number is remote)IP Address = 172.16.83.4 DADR=1



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.

When a Server object is created, you must specify the Point Access (1 or 2).The Type field is set to match the kind of object you are creating.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.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’.The Relinquish Default values are prefixed with the letter ‘R’.



Example 1Server BACnet Point

Point Access = 2 (Read/Write BACnet Server Point)Type = 2 (Analog Value)Instance = 8 (Instance is 8)Property = 85 (Present Value)BACnet Network = 1 (BACnet network number is 1)IP Address = <blank> (Not Required)



Example 2Server BACnet Point with Engineering Units

Point Access = 2 (Read/Write BACnet Server Point)Type = 2 (Analog Value)Instance = 32 (Instance is 32)Property = 85 (Present Value)BACnet Network = 1 (BACnet network number is 1)IP Address =

Units = 62 = (Deg Celsius)



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

Point Access = 2 (Read/Write BACnet Point BACnet Server)Type = 2 (Analog Value)Instance = 1 (Device Instance)Property = 85 (value)BACnet Network = 1 (BACnet network number is 1)IP Address =

Units = PercentRelinquish Default value = 50Priority Level = 5



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.

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.The Type must be set to 200 to specify this is the Device Self Object.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.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.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.The IP Address field is only used to change the default priority level and/or the BACnet/IP UDP Port address.



Example 1DeviceSelf Object

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



Example 2DeviceSelf Object with a specific UDP port address

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

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



Example 3DeviceSelf Object with default Priority Level

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



Priority Levels and Relinquish default

If no priority levels are assigned the XDriver uses priority level 10 for all commandable objects (Analog Output, Analog Value, Binary Output, Binary Value)If no priority level is assigned to the DeviceSelf object the XDriver uses this priority as its default priority level.If a priority level is assigned to any XDriver Server point then that priority level is used when that point is commanded.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.



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.



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 1Distribute 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 StateXdrvrClientObj = nState

Goto 2

Line 2



If nState <> Door1 State Then

nState = Door1 StateXdrvrClientObj = 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.



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 2Modify 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 = XdrvrSrvrObjDoor1 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



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 3Distribute Door Attribute Values to MNB-1000 or UNC/ENC Controllers 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 EntryLastCardXDrvrClientObj2 = Door1 EntryLastSiteXdrvrClientObj3 = Door1 EntryCount

EndIf

Line E

Goto 1



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.



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 StateFirstACX\XdrvrClientObj = nState

Goto 2

Line 2

If nState <> Door1 State Then

nState = Door1 StateFirstACX\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.



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 2Modify 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 = XdrvrSrvrObjSecondACX\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.



Program Type 3Distribute Door Attribute Values to MNB-1000 or UNC/ENC Controllers 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 EntryLastCardFirstACX\XDrvrClientObj2 = Door1 EntryLastSiteFirstACX\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.


Chapter 4web.Client


Introduction to the web.Client toolSystem and Pre-Installation Requirementsweb.Client Setup ConfigurationsHardware and Software Requirements for LAN SystemHardware and Software Requirements for a Standalone Systemweb.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.


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:

Create, search for, edit, and delete personnel recordsChange employee access privilegesView a person’s access eventsView and generate reports of all access events, including area access events, access events by persons, and distribution-event transactions via the Access Distribution ViewEdit and view schedules and calendars.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:

Create, run, and view graphical reports (class object Report), including bar charts, pie charts, trend charts, text reports, and so on.List and view graphics and groupsView live system alarms and live eventsView live video, as well as search for and view recorded video, via the class object, VideoLayout.



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.

.

Related Documents

DocumentDocument Number

Continuum web.Client Planning and Installation Guide for Version 1.81

30-3001-835

Andover Continuum CyberStation for TAC I/A Series Access Control Essentials Guide (Version 1.81)

30-3001-503

web.Client online help (Version 1.81)



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.



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:

A database serverDedicated workstations for configurationA dedicated web.Client application serverPCs 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 workstation, and the authorized personnel use web.Client on their own computers.

In the administration of a web.Client system, for example, you would be responsible for assigning privileges to engineering and manufacturing designees, who in turn are responsible for assigning all security privileges for engineering and manufacturing personnel.

Similarly, you could grant access rights to:

A coordinator to schedule a conference room and activate the lightingA technician to take control of a door during serviceA manager to search video for an incidentA facilities manager to graphically monitor and adjust building conditions and monitor alarms

Note: You will be installing either a web.Client for a LAN system or a standalone with web.Client. A LAN system has two servers: a database server and a web.Client application server. In a standalone system, the database and web.Client application reside on one server.





Differences between web.Client and CyberStation

web.Client is an extension of CyberStation. Through the convenience of a web browser, you can view, monitor, and in some cases modify objects and their values. (These include BACnet objects, since CyberStation and web.Client support the BACnet ANSI/ASHRAE standard.)

However, there are some differences between what your users can do in web.Client vs. CyberStation. You generally use web.Client to view and monitor objects that were defined in CyberStation. The following table lists the levels of support offered with each major web.Client feature. For information on web.Client features, see the web.Client online help.

web.Client Levels of SupportLEVELS OF web.Client SUPPORTFeature View Modify Delete CreatePersonnel X X X XSchedules and Calendars X X X

Events within schedules only

Events within schedules only

Reports X X XAreas XGroups XLoops X XGraphics XAlarms X XEvents XDistribution Events X X XPoints and objects X X X

Except: BACnet objects cannot be deleted.

TrendLogs X XVideo X a

a. Video can be modified, but not saved. For example, you can change cameras,show/hide time, change focus, zoom, but you will lose these changes if thepage is refreshed or you open another editor.

Doors X XController Web Pages X



Hardware and Software Requirements for LAN System

A web.Client LAN system has two server types:

Continuum/SQL database server IIS server (one for every 25 users)

If your system has no more than 25 users, select one server as the web.Client IIS server. This IIS server should be dedicated to running the web.Client application. For a larger LAN system (at least for any system having more than 25 users) your site must have more than one IIS server.

Depending on your particular LAN installation, the IIS server can be:

Windows XP Professional workstation (maximum of two users)Windows Server 2003 (maximum of 25 users per IIS server)

The IIS server must be on a network that can connect to the Continuum/SQL database server. The browser PCs should be on a network that can connect to the IIS server.

web.Client version 1.81 will upgrade any previous version on IIS server. web.Client 1.81 includes CyberStation 1.81, and installing it upgrades the IIS machine to 1.81. Workstations not at version 1.81



must be upgraded before installing web.Client. The following table shows the hardware and software requirements for the IIS server and the client browser on LAN systems:

The following software is recommended for LAN systems:

Hardware Requirements for IIS Server for LAN SystemsMinimum Recommended

1.6 GHz Pentium IV processora

a. Memory and processor speed - Performance is directly related to processorspeed and RAM. Increasing hard drive size allows for growth of applications(graphics, programs, and so on). Faster processor speeds and more RAMavailable to the program will increase performance.

2.4 GHz Pentium IV processor

512 MB RAM plus 5 MB per connection 1024 MB RAM plus 5 MB per connection20 GB hard drive (NTFS Partition) 40 GB hard drive (NTFS Partition)CD ROM drive CD ROM drive10/100 MB Ethernet Network Interface card



Note: Every connection to the IIS server by a browser PC accessing web.Client uses 5 MB of RAM on the IIS server. (For example, two browser PCs connected to the IIS server accessing web.Client use 10 MB of RAM on the IIS server. For this configuration, Schneider Electric recommends 512 MB plus 10 MB (used by the two PCs) or a minimum of 522 MB of RAM on the IIS Server.)

Software for LAN Systems

Tested & Supported Software for LAN Systemsa

Server Microsoft Windows XP Professional workstation, Service Pack 2. This accommodates up to two users.

OR:Microsoft Windows Server 2003 (Service Pack 1). This accommodates up to 25 users

OR:Microsoft Server 2003 R2. This accommodates up to 25 users.

Browser Internet Explorer 6.0, with Service Pack 1OR:

Internet Explorer 7.0

Internet IIS:Microsoft Windows XP: IIS 5.0Microsoft Windows Server 2003: IIS 6.0



The following table shows the Browser PCs that are recommended for LAN systems:

CyberStation Continuum CyberStation Version 1.81

Database SQL Server 2000 (Service Pack 4)OR:

SQL Server 2005

When you are prompted to select an authentication mode, select Mixed Mode. For more information, please see the Andover Continuum CyberStation Installation Guide, 30-3001-720.

Network protocol

TCP/IP

Other Microsoft .NET Framework version 2.0 (for web.Client)AND:

Microsoft .NET Framework version 3.0 (for Schneider Electric Video Layout Control)


a. Internet Explorer, IIS, and TCP/IP are included with the Microsoft operating systems.Upgrades and service packs are available free of charge from Microsoft’s web site,www.microsoft.com.

Browser PCs for Users on a LAN SystemTested & Supported Browser PCs for Users on a LAN SystemHardware SoftwareThe video feature requires network access to a digital video recorder. This may require you to open port 18772 or establish a Virtual Private Network (VPN) connection if there is a firewall.

The client browser PC on a LAN system can be running one of the following:

Windows XP Professional

Windows Server 2003

Internet Explorer 6.0, service pack 1OR:


Verify IE defaults are enabled for:Cookies and JavaScript

Software for LAN Systems

Tested & Supported Software for LAN Systemsa



Hardware and Software Requirements for a Standalone System

On a single-user standalone system with web.Client, the Continuum MSDE database, IIS, and the web.Client application are all installed on one Windows XP Professional workstation, or one Windows Server 2003.

web.Client version 1.81 will upgrade any previous version’s IIS server. web.Client 1.81 includes Cyberstation 1.81, and installing it upgrades the IIS machine to 1.81. Workstations other than the IIS server that are not at version 1.81 must be upgraded before installing web.Client. (Refer to the Andover Continuum CyberStation Installation Guide, 30-3001-720, for upgrade procedures.)

The following table lists hardware and software requirements for the IIS workstation and the client browser on standalone systems:

Note: The standalone system can accommodate two user connections (browser PCs). If you require more than two users, then you must upgrade to a LAN system.

Hardware Requirements for Standalone SystemsMinimum Recommended

1.6 MHz Pentium IV processora

a. Memory and processor speed - Performance is directly related to processorspeed and RAM. Increasing hard drive size allows for growth of applications(graphics, programs, and so on). Faster processor speeds and more RAMavailable to the program will increase performance.

2.4 GHz Pentium IV processor1

512 MB RAM 1024 MB RAM20 GB hard drive 40 GB hard driveCD ROM drive CD ROM drive10/100 MB Ethernet Network Interface card





The following table shows the software that is recommended for standalone systems:

Note: Every connection to the IIS server by a browser PC accessing web.Client uses 5 MB of RAM on the IIS server. For example, two browser PCs connected to the IIS server accessing web.Client use 10 MB of RAM on the IIS server. In this configuration, Schneider Electric recommends 512 MB plus 10 MB (used by the two PCs) or a minimum of 522 MB of RAM on the IIS Server.)

Software for Standalone SystemsTested & Supported Software for Standalone SystemsServer Microsoft Windows XP Professional workstation, Service Pack 2.

This accommodates up to two users.OR:

Microsoft Windows Server 2003 (Service Pack 1). This accommodates up to two users.

OR:Windows Server 2003 R2

Browser Internet Explorer 6.0, with Service Pack 1OR:


Internet IIS:

Microsoft Windows XP: IIS 5.0 Microsoft Windows Server 2003: IIS 6.0

CyberStation Continuum CyberStation Version 1.81

Database MSDE 2000 database engine with the Continuum database (Service Pack 4)

Network protocol

TCP/IP

Note: Internet Explorer, IIS, and TCP/IP are included with the Microsoft operating systems. Upgrades and service packs are available free of charge from their web site, www.microsoft.com.

Other Microsoft .NET Framework version 2.0 (for web.Client)AND:

Microsoft .NET Framework version 3.0 (for Video Layout Control)




The following table shows the browser PCs that are recommended for standalone systems:

Browser PCs for Users on a Standalone SystemTested & Supported Browser PCs for Users on a Standalone SystemHardware SoftwareThe video feature requires network access to a digital video recorder. This may require you to open port 18772 or establish a Virtual Private Network (VPN) connection if there is a firewall.

The client browser PC on a standalone system can be running one of the following:

Windows XP Professional

Windows Server 2003

Internet Explorer 6.0, with Service Pack 1OR:


Verify IE defaults are enabled for Cookies and JavaScript




Appendix ASupported AccessControl Elements

The following tables list the different access control elements shared by the integrated system that Plain English programs can reference.

First column: Lists the different categories of access control elements - Door attributes, ACX 57xx system variables, ACX 57xx points, and ACX 57xx point attributes. The values of any of these elements can be distributed to MNB-1000 or UNC/ENC controllers by creating Plain English programs that update one or more XDriver Client objects when element values change. Second column: Provides a description of each element.Third column: Indicates whether or not the element is read-only. Plain English programs can modify the values of some access control elements, if the element is not a read-only value. Fourth column: Indicates whether or not the element is a "one-scan" value, a value that exists for only one scan of the controller before reverting to its default value. Fifth column: The Program Type value in this column corresponds to the different example types from the Chapter 3 section, Programming Introduction. Sixth and Seventh columns: Lists the BACnet object type of the associated XDriver object, plus the permissible range of values that the access control element can take, respectively.


Appendix A : Supported Access Control Elements

Supported AcSupported Access Control Elements - Door Attributestrol Element

Door Attribute Name Description

Read-Only?

One-scan Value?

Pro-gram Type *

XDriver Object Type Values/Ranges

Alarm1 Whether Alarm 1 is active Yes No 1 Binary 0 = Not active1 = Active








AlarmValue Bitstring value of Alarm 1 - Alarm 8

Yes No 1 Analog 0 (no positions active) ... 255 (all positions active)

DoorAjar Whether the Door is open longer than door ajar time

Yes Yes 3 Binary 0 = False1 = True

DoorFault Bitstring value of door fault combinations 1 - 5

Yes No 1 Analog 0 (no faults are active) ... 31 (all faults are active)

DoorSwitch Value of the associated supervised input

Yes No 1 Analog 0 = Open1 = Closed2 = Trouble

Duress User has initiated a durress event.


EntEgrViolation Indicates if there any entry/egress violation.




EntryCount Number of cardholders entered on entry side of door

No No 1 or 2 Analog 0...65535

EntryLastCard Card number of the last person entered

Yes No 1 Analog 0...4294967295

EntryLastSite Site code of the last person entered

Yes No 1 Analog 0..65535

ExitCount Number of cardholders entered on exit side of door

No No 1 or 2 Analog 0...65535

ExitLastCard Card number of the last person exited

Yes No 1 Analog 0...4294967295

ExitLastSite Site code of the last person exited

Yes No 1 Analog 0...65535

ExitRequest Value of the associated supervised input

Yes No 1 Analog 0 = Open1 = Closed2 = Trouble

ForcedEntry A forced entry violation occurred

Yes No 1 Binary 0 = False1 = True

InvalidAttempt An invalid card was used. Yes Yes 3 Binary 0 = False1 = True

LastPersEntrdDep Department number of the last person entered

Yes No 1 Analog 0...4294967296

LastPersExitdDep Department number of the last person exited

Yes No 1 Binary 0...4294967296

MomentaryUnlock Unlocks the door for a definite amount of time.

N No 1 or 2 Binary 0 = False1 = True

Override Indicates if the door has been overridden.


OverrideValue Indicates the actual value of the door when it has been overridden.




Read-Only?

One-scan Value?

Pro-gram Type *




PermanentUnlock Unlock the door indefinitely.

No No 1 or 2 Binary 0 = False1 = True

State Indicates whether the door is currently enabled.

No No 1 or 2 Binary 0 = Disabled1 = Enabled

ValidAccess Indicates a valid access through the door.


Value Indicates the state of the door.

Yes No 1 Analog 0 = Unlocked1 = Locked

* Program Type1 = Distribute value to BACnet/IP network2 = Modify value via BACnet/IP network3 = Distribute one-scan value to BACnet/IP Network



Read-Only?

One-scan Value?

Pro-gram Type *


SuppSupported Access Control Elements - ACX 57xx System VariablesElementACX 57xx System Variable Description

Read-Only?

One-scan Value?

Pro-gram Type*


CabinetTamper Value of the CabinetTamper system variable

Yes No 1 or 2 Analog 0 = False1 = True

SystemStatus Value of the SystemStatus system variable

Yes No 1 or 2 Analog 0 = Coldstart1 = Normal2 = NoComm3 = NoDatabase

Rdr1Connected Indicates whether a reader is connected to Channel 1.

Yes No 1 or 2 Analog 0 = No reader connected1 = Reader connected


















SuppSupported Access Control Elements - ACX 57xx System VariablesElementACX 57xx System Variable Description

Read-Only?

One-scan Value?

Pro-gram Type*




SuppSupported Access Control Elements - ACX 57xx PointsElement

ACX 57xx Point Description

Read-Only?

One-scan Value?

Pro-gram Type*


Door Force Lock(Schedule Numeric)

Value of the associated Numeric object

No No 1 or 2 Binary 0 = All access disallowed1 = Door opens normally

Door Force Unlock(Schedule Numeric)


No No 1 or 2 Binary 0 = Access control in effect1 = Door is permanently unlocked

AreaLink (Schedule parameter Numeric)


No No 1 or 2 Binary 0 = All access disallowed1 = Door opens normally

Output objects Value of the associated Output object

No No 1 or 2 Analog 0...n

Input objects Value of the associated Input object

Yes No 1 Analog 0...n




SuppSupported Access Control Elements - Attributes of ACX 57xx PointsElement

ACX 57xx Point Attribute Description

Read-Only?

One-scan Value?

Pro-gram Type*


Alarm1 Indicates whether Alarm 1 is active.

Yes No 1 Binary 0 = Not active1 = Active















AlarmValue Bitstring value of Alarm 1...8

Yes No 1 Binary 0 = (no positions active) ... 255 (all positions active)





Appendix BBest Practices

This appendix contains the following topics:

Tips for successful implementation


Appendix B: Best Practices

Tips for Successful Implementation

1. Limit the number of XDriver Server objects. At most, the system should use one Server object for each access control element requiring external control. The system should be primarily comprised of XDriver Client objects that update objects external to the ACX 57xx controller, as required.

2. Copy objects in Offline mode. When creating multiple XDriver Client objects you may wish to use the Copy feature to create these objects more quickly. To perform this task most efficiently:

a. Begin with the workstation online and an initial XDriver Client object created in the ACX 57xx.

b. Put the workstation offline, then select the object in Continuum Explorer.

c. Drag and drop the object one or more times in the same ACX 57xx con-troller object.

d. Open each object and provide whatever unique information is required (generally, a unique Instance and Object Type combination).

e. Save all of the changes and make the workstation online.f. Select each newly created object and perform a Send To Controller

operation. 3. Test XDriver Client objects before referencing them in a

program. Before referencing an XDriver Client object in a program, test whether the object is correctly configured. Change the XDriver Client object's value and determine whether the corresponding object in the external device is updated.

4. Test XDriver Server objects before referencing them in a program. Before referencing an XDriver Server object in a program, test whether an external device can modify the object.

5. Use short names for objects, whenever possible. When creating XDriver Client or Server objects, use 16 or fewer characters for object names. This practice reduces the amount of manual coding in programs and keep the object name in the database and controller consistent. Objects names should also not



contain spaces, and characters other than "." and "_", and should begin with an alpha character.

6. Use a unique Instance for the DeviceSelf Object. The Instance value of the DeviceSelf Object determines its BACnet Object Identifier. Ensure that this value conflicts with no other device on the BACnet inter-network, as unpredictable behavior might occur.

7. Make all programs Looping and Autostart. When creating Plain English programs always configure the program to be Autostart and Looping. These settings cause the program to begin whenever the controller starts or when a change to the program is saved. They also will cause the program to remain running unless an error occurs.

8. Use a "Line E" in all Programs. This prevents programs from disabling when a run-time error occurs. The most common cause of a run-time error is when a remote device cannot be contacted.

9. Limit the number of referenced objects to 100.Limit the number of objects that a single program references to 100. This includes XDriver Client and Server objects. Multiple programs can be utilized to accommodate greater numbers of point value distributions.

10. Group One-Scan Attributes in the same program.Group as many one-scan attributes in the same program as possible. This practice tends to reduce the overall application complexity.

11. Disable the ReadPropertyMultiple requests, if more than 10 XDriver Server objects are referenced from the same Enterprise Server.If 10 or more XDriver Server objects are referenced from the same Enterprise Server, the Device object for the ACX 57xx controller should be configured to not use ReadPropertyMultiple requests. To disable the initiation of ReadPropertyMultiple requests use the appropriate setting in the Configuration tab of the Properties page for the applicable ACX 57xx device in the Enterprise Server/WorkPlace Pro.



12. When configuring the Parameters for a Client XDriver point that will distribute values to another BACnet/IP device, make sure the BACnet Network value (Parameter 5) matches the BACnet Network value for the DeviceSelf object. The Client XDriver object does not send updated point values if these values are different.


Appendix CRelated Documents

and Resources

The following table contains related documents referenced in this guide as well as additional resources useful in implementing the Continuum - I/A Series integrated access control system:

Document Name Part Number

Andover Continuum CyberStation Installation Guide for Version 1.81

30-3001-720

Continuum CyberStation Configurator’s Guide 30-3001-781

Continuum CyberStation Configurator’s Guide Addendum - 1.81 30-3001-880

Andover Continuum CyberStation Plain English Language Reference

30-3001-872

Andover Continuum web.Client Planning and Installation Guide 30-3001-835

Andover Continuum Security and TAC I/A Series Access Control Essentials Guide

30-3001-503

ACX 57xx Series Controller Operation and Technical Reference Guide

30-3001-999


Appendix C: Related Documents and Resources

Continuum online help

web.Client online help

Niagra BACnet Integration Reference

TAC I/A Series MicroNet BACnet Wiring and Networking Guide F-27360-2

Workplace Tech Tool 5.6 Engineering Gide Supplement - See “Applicable Doc Table”, page iv

F-27356-2

TAC I/A Series MicroNet BACnet WorkPlace Commissioning Tool and Flow Balance Tool User’s Guide

F-27358

Document Name Part Number


Andover Continuum Security and TAC I/A SeriesData Exchange Reference GuideDocument Number 30-3001-406

Revision B