Handshake V3.0 1 0 en Man

handshake™ 3.0 – User manual

© 2006 SKIDATA AG Page 2 of 2

Version 1.0 July 2006 handshake™ Version 3.0 SKIDATA AG Untersbergstraße 40 A-5083 Grödig/Salzburg Telefon: +43 (0) 62 46/8 88-0 Telefax: +43 (0) 62 46/8 88-7 Internet: http://www.skidata.com/ e-mail: [email protected] Copyright © 2006 by SKIDATA AG. All rights reserved. All information in the following document is protected by copyright law. No part of this document may be reproduced without the written consent of SKIDATA AG. SKIDATA AG reserves the right to make any changes of specification and other information in this document without further notice. Please Note During the compilation of this Technical Documentation, great care has been taken to ensure the accuracy of the information contained in it. However, despite our constant effort to ensure the highest degree of accuracy and comprehensiveness possible, the information provided cannot be guaranteed to be absolutely error-free. Trademarks This documentation may contain representations of registered product or service trademarks owned by SKIDATA AG or third parties, as well as references to proprietary know-how protected by copyright laws or other legal provisions. In any case the intellectual property rights remain exclusively with their respective owners.

Handshake.Logic – Table of Contents 1

1 Table of Contents

Version 3.0 / 1.0 8 Pages Copyright 2006 by SKIDATA AG

1 Handshake.Logic – Table of Contents 1.1 Overall Contents

Page 2 © SKIDATA AG, Version 3.0 / 1.0

1.1 Overall Contents

Table of Contents 1

1.1 Overall Contents 2

Introduction, system description 2

2.2 About this documentation 3 2.2.1 Transfer of documentation 3 2.2.2 Structure of this document 3

2.3 Typographical conventions 4 2.3.1 Text 4 2.3.2 Symbols 4

2.4 System description 5 2.4.1 System concept 5 2.4.2 handshake™ Explorer 6 2.4.3 Reporter 7 2.4.4 Access Manager 8 2.4.5 SKIDATA Monitor 9 2.4.6 Messaging 10 2.4.7 Archiv – the data storage 11 2.5 Operating system and software

environment 12

2.6 User interface and program operation 13 2.6.1 Controls 14 2.6.2 Direction symbols 15

2.7 What's new in version 3.0? 21 2.7.1 Chapter 3 Explorer 21 2.7.2 SKIDATA Monitor 21 Explorer 3

3.1 Contents 2

3.2 Handshake.Logic 5 3.2.1 handshake™ Explorer 5

3.3 Boot-up and installation 6 3.3.1 Initial installation 7 3.3.2 Update 7 3.3.3 Logout 8 3.3.4 Login 8 3.3.5 Synchronize 9


Overall Contents 1.1

© SKIDATA AG, Version 3.0 / 1.0 Page 3

3.4 Client, user and employee management 11 3.4.1 Client administration 12 3.4.2 User administration 13 3.4.3 Employee administration 16

3.5 Venue administration 18 3.5.1 Overviews 18 3.5.2 Event venue 20 3.5.3 Layout 25 3.5.4 Areas 27 3.5.5 Gate 28 3.5.6 Checkpoints 31 3.5.7 General 31 3.5.8 Reader parameter 34 3.5.9 Barrier parameters 42 3.5.10 Modes 50 3.5.11 Copy checkpoints 51 3.5.12 Access Manager 52 3.5.13 Checkpoint modes 53

3.6 Time periods 57 3.6.1 Reader periods 57 3.6.2 Regular periods 58

3.7 Ticketsystem configuration 59 3.7.1 System settings 60 3.7.2 Ticket system 61 3.7.3 Code definitions 69 3.7.4 RF coding 72 3.7.5 Mifare conversion 74 3.7.6 Properties 78 3.7.7 Imports 83 3.7.8 Exports 87 3.7.9 Extended checks 89 3.7.10 Result codes 93

3.8 Access configuration 95 3.8.1 Event overview 96 3.8.2 Events 96 3.8.3 Permission types 97 3.8.4 Checks 102 3.8.5 Actions 113 3.8.6 Point deduction 117 3.8.7 Error actions 119 3.8.8 Counter 127 3.8.9 System counter 127 3.8.10 User counter 128



3.8.11 Blacklist 132 3.8.12 Data medium blocks 133 3.8.13 Permission blocks 135

3.9 Journal 137

3.10 Test mode 138 3.10.1 Activating test mode (one layout) 140 3.10.2 Activating test mode (more than one

layout) 140 3.10.3 Deactivating test mode (one layout) 141 3.10.4 Deactivating test mode (more than one

layout) 142

3.11 Archive 143

Reporter 4

4.1 Contents 2

4.2 Reporter 3 4.2.1 Requirements and program operation 4 4.2.2 Error message 6

4.3 Admission statistics 7 4.3.1 Admission statistics – Total 8 4.3.2 Admission statistics – Comparison 11 4.3.3 Fill level – visitors 13

4.4 Visitor frequency analysis 15 4.4.1 Visitor Frequency analysis – Day analysis 16 4.4.2 Visitor frequency analysis – Period analysis21

4.5 Length of stay 25 4.5.1 Length of stay 26

4.6 Irregularities 30 4.6.1 Occurred error codes 30 4.6.2 Details 32 4.6.3 Restrictions 34 4.6.4 Categories 36

4.7 Ticket Data 38 4.7.1 Ticket use 38 4.7.2 Ticketdata 40 4.7.3 Whitelistdata 42

Access Manager 5

5.1 Contents 2


Overall Contents 1.1


5.2 Access Manager 3

5.3 Start 4

5.4 Screen layout 5 5.4.1 Menu bar 5 5.4.2 Tool bar 6 5.4.3 Checkpoint window 6 5.4.4 Status bar 6

5.5 Checkpoint window 7 5.5.1 Transactions 7 5.5.2 Control functions 11 5.5.3 Statistics counters 13 5.5.4 Arranging the checkpoint windows 14 5.5.5 Changing checkpoint window size 15

Messaging 6

6.1 Contents 2

6.2 Messaging 3

6.3 Installation and basic settings 4 6.3.1 Initial installation 4 6.3.2 Assigning user rights 5 6.3.3 Running the Messaging client 6 6.3.4 Basic settings 6

6.4 User interface and program operation 7 6.4.1 Screen layout 7 6.4.2 Creating a new messaging alert 9 6.4.3 ‘General’ tab 10 6.4.4 ‘Statistics’ tab 11 6.4.5 ‘Checkpoint / Access Manager / server’ tab12 6.4.6 ‘Counter’ tab 13 6.4.7 ‘Message’ tab 14 6.4.8 ‘Schedule’ tab 17 6.4.9 'Response' tab 19 Archive 7

7.1 Contents 2

7.2 Archive 3

7.3 Installation 4 7.3.1 Assigning user rights 4 7.3.2 Running the Archive 5 7.3.3 Basic settings 5



7.4 User interface and program operation 6 7.4.1 Database backup 7 7.4.2 Purging the database 9 7.4.3 Creating an archive 15 7.4.4 Archive mode 17

Technical Terms 8

8.1 Contents 2 8.1.1 A 3 8.1.2 B 3 8.1.3 C 3 8.1.4 D 5 8.1.5 E 5 8.1.6 F 6 8.1.7 G 6 8.1.8 H 7 8.1.9 I 7 8.1.10 L 7 8.1.11 M 7 8.1.12 N 8 8.1.13 O 8 8.1.14 P 8 8.1.15 R 9 8.1.16 S 10 8.1.17 T 10 8.1.18 U 10 8.1.19 V 10 8.1.20 W 10 8.1.21 X 10

Empty Pages 9

Handshake.Logic – Introduction, system description 2

2 Introduction, system description


2 Handshake.Logic – Introduction, system description 2.1 Contents


2.1 Contents

2.1 Contents 2

2.2 About this documentation 3 2.2.1 Transfer of documentation 3 2.2.2 Structure of this document 3

2.3 Typographical conventions 4 2.3.1 Text 4 2.3.2 Symbols 4

2.4 System description 5 2.4.1 System concept 5 2.4.2 handshake™ Explorer 6 2.4.3 Reporter 7 2.4.4 Access Manager 8 2.4.5 SKIDATA Monitor 9 2.4.6 Messaging 10 2.4.7 Archiv – the data storage 11

2.5 Operating system and software environment 12

2.6 User interface and program operation 13 2.6.1 Controls 14 2.6.2 Direction symbols 15 2.6.2.1 New 15 2.6.2.2 Copy 16 2.6.2.3 Edit I 17 2.6.2.4 Delete 17 2.6.2.5 Assign and remove 18 2.6.2.6 Sort 19 2.6.2.7 Search and filter 19 2.6.2.8 Link to details 20 2.6.2.9 Navigation bar 20 2.6.2.10 Information dialogues and error messages 20 2.7 What's new in version 3.0? 21 2.7.1 Chapter 3 Explorer 21 2.7.2 SKIDATA Monitor 21


About this documentation 2.2


2.2 About this documentation

This document contains information and operating instructions for the Handshake.Logic.

2.2.1 Transfer of documentation

Recipients of this documentation must be held not to pass the documentation on to others or to copy or electronically store it other than for their own use.

2.2.2 Structure of this document

Chapter 1 is the reference register of this manual.

Chapter 2 (this chapter) contains general comments on this documentation and a system description as well as instructions on the use of the web based user interface.

In Chapter 3, you will find information on the usage and a func-tional description on the handshake™ Explorer.

Chapter 4 is a description of the Reporter.

Chapter 5 describes use and function of the Access Manager.

Chapter 6 contains the description of the Messaging client.

The Archive process is described in Chapter 7.

Chapter 8 is a reference of the technical terms.

Chapter 9 has empty pages for your own notes.

2 Handshake.Logic – Introduction, system description 2.3 Typographical conventions


2.3 Typographical conventions

Text passages of particular importance are highlighted by a dif-ferent layout and special symbols.

2.3.1 Text

Step-by-step instructions and listed items are printed in the form of bulleted lists . . .

just like this one

Important hints and notes are printed in a box. Text passages like this usually caution the user against potential technical damage or health hazards. Boxed messages may also contain special instructions.

2.3.2 Symbols

The following symbols are used throughout this document:

Important: Warning against personal injury or technical damage.

Note: Information regarding the appropriate use of a device or important hints, explanations, etc.

All components of the access control system have been in-spected for safety. Potential remaining hazards will be pointed out in system training, in the user documents and in this manual.


System description 2.4


2.4 System description

Handshake.Logic is a fully novel concept. The challenge lies in the custom solution of access control on one hand, and on the in-tegration to ticketing systems from different sources throughout the world.

2.4.1 System concept

Fig. 1: System concept

2 Handshake.Logic – Introduction, system description 2.4 System description


2.4.2 handshake™ Explorer

The handshake™ Explorer is the tool for the system administra-tor. MS-Internet Explorer based management software allows the administrator in a simple way to group access terminals to en-trances and administer crossing passages between visitor areas. Even if this configuration changes between events.

The System administrator can define for each ticket category, which ticket may pass which checkpoint at what time and how many times it has authorisation to enter specific areas. For the individual check points, various modes of operation can be se-lected to grant the highest level of security control.

To offer the operator maximum flexibility, handshake™ Explorer can be run on every PC workstation in the network. By simply connecting to the handshake™ Server with Internet Explorer us-ers can access all Handshake.Logic information. Built-in authori-zation management guarantees secure access and user control on the handshake™ server.

Fig. 2: handshake™ Explorer




2.4.3 Reporter

An automated ticket control system provides the operator with a most valuable data base for security and marketing considera-tions – specifically when ticket inspection is carried out at the ex-its as well. To that end, handshake™ provides an open interface. Ticket transactions can be exported to a data warehouse system. Lists and Graphs can be generated in Reporter.

To offer the operator maximum flexibility, Reporter can be run on every PC workstation in the network. By simply connecting to the handshake™ Server with Internet Explorer users can access all handshake™ system information. Built-in authorization manage-ment guarantees secure access and user control on the hand-shake™ server.

Fig. 3: Reporter



2.4.4 Access Manager

The Access Manager is the core of the handshake™ system and includes all processes required to evaluate the tickets and control the access terminals. It determines how many times a ticket can open an access gate at a given time. With programmable block-ing and reuse control periods, misuse can be prevented.

The Access Manager can be used to manage several venues such as halls, stadiums and visitor areas in parallel.

The decentralised Access Manager has two basic key functions:

to provide the functionality of a “hardware hub” in configura-tions where the readers are networked via Arcnet connections

to relieve the server by taking on part of the processing load in configurations involving Ethernet-based readers or a large number of gates

Fig. 4: Access Manager




2.4.5 SKIDATA Monitor

The SKIDATA Monitor has two main functions: monitoring the en-tire system, and performing certain system activities. An overview and detailed view are provided for both tasks, with each system component being represented by an icon and the corresponding device status indicated by colour codes.

Fig. 5: SKIDATA Monitor



2.4.6 Messaging

It’s essential to be well informed. With Messaging you’ll get a tool that will keep you updated on admission activities at the access gates. You won’t have to request reports or issue system queries yourself, as handshake™ will do it for you automatically. To make sure that you receive only the information relevant to your needs, the system features configuration options to system events, communication channels and recipient profiles. This way, you can have the system notify you of important system events such as the admission of the ten thousandth visitor or a VIP guest. Administrators will also appreciate the option of being notified of status changes at the checkpoints. These messages can be sent via various communication channels such as SMS, e-mail, and various others.

Fig. 6: Messaging




2.4.7 Archiv – the data storage

This feature is designed to help keep the data volume accumu-lated within the handshake™ system within a reasonable limit. Archiving permissions are managed via handshake™ user ad-ministration.

This function allows for expired or obsolete transaction and con-figuration data to be extracted and deleted from the on-line data-base. As a result, system performance is kept at an optimum level.

When a stored database is restored, it is automatically adapted to the latest handshake™ version and made available to the user as a separate ‘read-only’ database. When logging into handshake™ Explorer, users are free to decide whether they wish to view the data of the on-line database or those retrieved from the archive.

Fig. 7: Archiv

2 Handshake.Logic – Introduction, system description 2.5 Operating system and software environment


2.5 Operating system and software environment

The Handshake.Logic works on the basis of the following Micro-soft products:

WEB Server Architecture Windows 2000 / 2003 Server as Industrial Standard MS SQL Server 2000 Database Management System MS Internet Information Server MS .NET Framework Visual Basic, Visual C++ as programming language


User interface and program operation 2.6


2.6 User interface and program operation

The handshake™ Explorer as well as the Reporter are INTER-NET Explorer based management and reporting applications.

Should you require help with using MS-Internet Explorer, please use the built-in help function. There, you will find a variety of ways to get the answer to your particular question – from a help index to product updates and much more. To view the help func-tion content, press the F1 key.

Fig. 8: The handshake™ Explorer

2 Handshake.Logic – Introduction, system description 2.6 User interface and program operation


2.6.1 Controls

Version Information

Version details are displayed in the Internet Explorer title frame (top left) and in the status bar (bottom left).

Program selection

The program menu lets you select Explorer for performing man-agement tasks and the Reporter for generating system reports. Synchronisation transfers the current information to all front-ends. Setup must be run when installing new components on a workstation. To select another client you need to Logout first.

Client information

The client information displays the currently selected client.

Archive

Within the handshake™ explorer the switch between Online (life-data) and Archive database (old data) is possible, to do so, click on the A symbol. The symbol will be available after the first time the archive process was started in the handshake™ Archive.

Test mode

Test Mode works with actual tickets. When leaving Test Mode, you can decide whether or not the test data created during your testing session should be converted to real data so the tickets can not or can be reused. Test Mode can easily be activated and deactivated by clicking the corresponding symbol.

Online help and SKIDATA AG web site access

The online help comes as PDF based help file and is not imple-mented yet it can be found on the documentation CD. If you re-quire additional information about SKIDATA AG, the SKIDATA AG home page will be opened in a separate browser window.

New, Copy, Edit and Delete

Records are created, copied (only for layout and checkpoints), edited and, when necessary, deleted.




Link to detail information

To view more detailed information, you click on a link (underlined word). The detail is displayed in the browser window.

Menu

Management of the handshake™ system is organised on various levels. To preview all options of an area (User Management, for instance), click the + on the left of the area name. The – indicates that this sub-tree is already fully expanded (i.e., all submenus for this tree node are already displayed).

Navigation bar

The navigation bar shows the level of the displayed information. It allows you to change to a different level by clicking it, thus allow-ing you to move back and forth.

2.6.2 Direction symbols

To show the direction for actions and checks following symbols are in use

Entry

Exit

both directions

not in use

2.6.2.1 New

Depending on which program level you are working in, a new re-cord can be created. After entering data in the open window, you can save them by clicking the Apply Button. The window remains open and the next record can be entered. To close the window, click the OK button. Using Cancel will reject the input.



Note: Using the Apply button will store the data record and a new data set can be put in immediately. The list containing the actual values (main page) will NOT be refreshed!

2.6.2.2 Copy

The copy feature is available to copy layouts and checkpoints. To copy either a layout or checkpoints the click on the copy button will bring up the corresponding window in which the copy process can be started.

Fig. 9: New record

Fig. 10: Copy




2.6.2.3 Edit I

With the edit function, existing data can be modified and adapted. The modified data is saved using the Save button, whereupon the window is closed. Pressing the Close button results in closing the window without saving the changes.

2.6.2.4 Delete

In order to delete previously created data, you need to confirm the confirmation message check with “yes”. Please note the data deletion warning.

Fig. 11: Edit record

Fig. 12: Delete record



2.6.2.5 Assign and remove

Some input dialogues allow you to assign data from lists or re-move existing assignments.

Use the double right arrow >> to assign all data from the list in one go. Use the single arrow > to assign only selected entries (those highlighted in blue). To select multiple entries at once, you can use the Windows standard item selection method (Shift + left-click to select a block of consecutive entries, or Ctrl + left-click to pick individual entries).

Use the arrow left button < to remove assigned data from a list. Clicking the double arrow << will remove all assigned entries; the single arrow will remove only the selected entries.

Fig. 13: Assign or reassign




2.6.2.6 Sort

If the header of a column is shown in yellow colour, the column can be sorted in ascending or descending order by clicking on the column header. The sort order is ascending by default.

2.6.2.7 Search and filter

When a list contains more than 50 entries, the display is split. Be-fore the information is displayed, a search has to be started. The number of results shown on the page can be selected. Under-neath the list the navigation between the pages is possible. Search and filter is available on the following pages:

Ticket property Imports Data medium blocks Permission blocks Journal Analysis mode

Fig. 14: Sort

Fig. 15: search and filter



2.6.2.8 Link to details

Clicking a link will bring up the corresponding details.

2.6.2.9 Navigation bar

The best way of navigating to individual program levels is by us-ing the navigation bar at the bottom of the screen. This bar al-ways shows the currently active level.

2.6.2.10 Information dialogues and error messages

Information dialogues and error messages can be uniquely identi-fied by means of the number shown in the title bar of the mes-sage/dialogue window. The title bar also identifies the system area associated with the message. This facilitates troubleshoot-ing and ensures proper error identification when consulting Tech-nical Support.

Fig. 16: Follow a link

Fig. 17: Navigation bar

Fib. 18: Information dialogue


What's new in version 3.0? 2.7


2.7 What's new in version 3.0?

2.7.1 Chapter 3 Explorer

3.4.3 Employees Show employees ID

3.5.8.2 Configuring reader type two way reader AS x70i CF/V2 Two readers AS x70i CF/V2 are mounted on one turnstile DKZ x70i of ADA turnstile

3.5.9.1 Configuring turnstile SKIDATA™ DKZ x70i Configurable barrier timeout is used in emergency mode

3.5.13.1 New / edit checkpoint modes Checkpoint modes can be set up for each layout

3.7.10.1 New result code 3.7.9 Extended checks

Using the open programmable Extended.Check Interface ad-ditional checks for the ticket can be set up.

3.7.9.2 Plugin for Print@Home tickets from Fair system 550 Parksystem Parking.Logic and Handshake.Logic

The new Software Version introduces a special web service based programming interface for system independent integra-tion of parking system Parking.Logic into external systems. Compatibility between Handshake-Logic and Parking.Logic Version 1.0 is achieved through an on-line ticket polling inter-face.

3.8.5 Actions New variable text messages can be used for all actions and error actions.

3.8.11 Blacklist Extended possibilities for the Blacklist

3.10 Test mode Each layout can be switched to test mode separately.

2.7.2 SKIDATA Monitor

The new, revised Monitor application is based on a modular structure and is based on a new client-server architecture. This reduces the network load of the Handshake.Logic system and has the added benefit of allowing the Monitor application to be used with various SKIDATA™ systems – a clear proof of the modularity of all SKIDATA™ systems. The graphic user surface provides a new, improved look and feel. The SKIDATA Monitor description is no longer part of this user manual. There is an own manual available describing all Monitor functions.

2 Handshake.Logic – Introduction, system description 2.7 What's new in version 3.0?


Handshake.Logic – Explorer 3

3 Handshake™ – Explorer


3 Handshake.Logic – Explorer 3.1 Contents


3.1 Contents

3.1 Contents 2

3.2 Handshake.Logic 5 3.2.1 handshake™ Explorer 5

3.3 Boot-up and installation 6 3.3.1 Initial installation 7 3.3.2 Update 7 3.3.3 Logout 8 3.3.4 Login 8 3.3.5 Synchronize 9

3.4 Client, user and employee management 11 3.4.1 Client administration 12 3.4.2 User administration 13 3.4.2.1 Assign new user 13 3.4.2.2 Modify user right 15 3.4.3 Employee administration 16 3.4.3.1 New employee 16 3.5 Venue administration 18 3.5.1 Overviews 18 3.5.1.1 Global overview 18 3.5.1.2 Checkpoint usage 19 3.5.2 Event venue 20 3.5.2.1 Event venue upper limit 20 3.5.2.2 Checkpoint default behaviour 21 3.5.3 Layout 25 3.5.3.1 Copy layout 27 3.5.4 Areas 27 3.5.5 Gate 28 3.5.6 Checkpoints 31 3.5.7 General 31 3.5.8 Reader parameter 34 3.5.8.1 Configuring reader type AS x70i CF / AS x70i CF/V234 3.5.8.2 Configuring reader type two way reader AS x70i

CF/V2 35 3.5.8.3 Configuring reader type OBID-classic-pro 37 3.5.8.4 Configuring parking column AS450 38 3.5.8.5 Configuring reader type KeyDetector DUO 39 3.5.8.6 Configuring reader type Handheld Terminal AS x70i

HH 40 3.5.8.7 Handheld interface 41 3.5.9 Barrier parameters 42 3.5.9.1 Configuring turnstile SKIDATA™ DKZ x70i 42 3.5.9.2 Configuring SKIDATA™ ADA turnstile 43 3.5.9.3 Generic turnstile (with SD676) 44

handshake™ – Explorer 3

Contents 3.1


3.5.9.4 Via reader I/O 46 3.5.9.5 Third party barrier (with SD676) 47 3.5.9.6 Counting turnstile DKZ x70i 47 3.5.9.7 Configuring barrier type AS 450 ASL 49 3.5.10 Modes 50 3.5.11 Copy checkpoints 51 3.5.12 Access Manager 52 3.5.13 Checkpoint modes 53 3.5.13.1 New / edit checkpoint modes 54 3.6 Time periods 57 3.6.1 Reader periods 57 3.6.2 Regular periods 58

3.7 Ticketsystem configuration 59 3.7.1 System settings 60 3.7.1.1 Day change 60 3.7.1.2 Extended checks 60 3.7.1.3 Extended emergency mode 61 3.7.2 Ticket system 61 3.7.2.1 General 62 3.7.2.2 Interfaces 63 3.7.2.3 File format generic 65 3.7.2.4 File format XML 65 3.7.2.5 File format Nessie 65 3.7.2.6 Keywords 66 3.7.2.7 Transmission type file system 67 3.7.2.8 Transmission type FTP 67 3.7.2.9 Transmission type server / client socket 68 3.7.3 Code definitions 69 3.7.3.1 General 69 3.7.3.2 Input parameter 71 3.7.3.3 Keywords 72 3.7.4 RF coding 72 3.7.5 Mifare conversion 74 3.7.5.1 Configure Mifare security keys 76 3.7.6 Properties 78 3.7.6.1 Individual ticket property 79 3.7.6.2 Grouped ticket property 81 3.7.6.3 Ticket properties with control functionality 82 3.7.7 Imports 83 3.7.7.1 Activate ticket properties 86 3.7.8 Exports 87 3.7.9 Extended checks 89 3.7.9.1 Two step validation 90 3.7.9.2 Plugin for Print@Home tickets from Fair system 55092 3.7.10 Result codes 93 3.7.10.1 New result code 94

3 Handshake.Logic – Explorer 3.1 Contents


3.8 Access configuration 95 3.8.1 Event overview 96 3.8.2 Events 96 3.8.3 Permission types 97 3.8.3.1 Season Ticket 98 3.8.3.2 Day Ticket 98 3.8.3.3 Day Ticket (non consecutive days) 98 3.8.3.4 Point value 99 3.8.3.5 Time-Based Ticket 99 3.8.3.6 Groupticket 99 3.8.3.7 Set up a permission 100 3.8.4 Checks 102 3.8.4.1 Permit 102 3.8.4.2 Denial 105 3.8.4.3 Restrictions 106 3.8.4.4 Control functions 109 3.8.4.5 Validity check 110 3.8.4.6 Conditions 110 3.8.4.7 Extended emergency mode 112 3.8.4.8 Ticket check procedure 112 3.8.5 Actions 113 3.8.6 Point deduction 117 3.8.7 Error actions 119 3.8.8 Counter 127 3.8.9 System counter 127 3.8.10 User counter 128 3.8.10.1 Creating and editing counters 129 3.8.10.2 Counter configuration 129 3.8.10.3 Assigned locations 131 3.8.10.4 Assigned identifications 132 3.8.11 Blacklist 132 3.8.12 Data medium blocks 133 3.8.13 Permission blocks 135

3.9 Journal 137

3.10 Test mode 138 3.10.1 Activating test mode (one layout) 140 3.10.2 Activating test mode (more than one

layout) 140 3.10.3 Deactivating test mode (one layout) 141 3.10.4 Deactivating test mode (more than one

layout) 142

3.11 Archive 143


Handshake.Logic 3.2


3.2 Handshake.Logic

As an access management system, Handshake.Logic combines a high degree of flexibility with controlled, secure access.

The focal points are custom solutions for access control require-ments on one hand, and interfacing with ticketing systems from all over the world. The Handshake.Logic Access System has a modular design. With its

handshake™ Explorer handshake™ Reporter handshake™ Access Manager and other optionally available additional modules

it allows events to be perfectly planned, executed and controlled throughout all stages. Handshake.Logic is based upon the latest Microsoft technology and uses MS SQL Server as a database engine. The handshake™ Explorer and handshake™ Reporter utilize MS-Internet Explorer as a cost-effective and up-to-date user environment. This also allows access from any computer with an Internet connection.

3.2.1 handshake™ Explorer

The handshake™ Explorer is the central tool for the system ad-ministrator. It predominantly serves all purposes of management and administration of configuration and event data. Using hand-shake™ Explorer, configurations of all events can be adapted freely to the requirements of each event.

The user management falls back on the existing user structure within the Windows 2000 environment. Thus, every user within a network has access to the handshake™ Internet address. The pre-defined user rights scheme regulates the functions which can be accessed by each user.

Client and user management Configuration data management Event data management Access management

3 Handshake.Logic – Explorer 3.3 Boot-up and installation


3.3 Boot-up and installation

Launch the Microsoft Internet Explorer and make sure the follow-ing parameters of the Internet Explorer’s Security settings (Tools – Internet Options – “Security” tab – local Intranet – Custom level) are activated:

Initialize and script ActiveX controls not marked as safe Run ActiveX controls and plug-ins Script ActiveX controls marked as safe for scripting

Enter the URL (e.g., http://handshakeserver/handshake/) to load the start page of the handshake™ system.

If there is only one client in the system, users, independent of their rights, will be directed to the start page. Program functions will be available, depending on the user’s role. In case of more than one client, the current client needs to be selected first.

Fig. 1: handshake™ Explorer


Boot-up and installation 3.3


Note: If you designate this location your start page, you will find yourself in the handshake™ environment directly after starting Internet Explorer!

3.3.1 Initial installation

Make sure all required components are installed on the server before running the system on a workstation for the first time.

Important: Initial installation and updating can be performed by users with administrator rights only!

For this, click Setup in the program selection bar and select open to run the installation procedure. During installation, the re-quired components are stored on your computer and registration entries are put in place.

For this follow the instructions displayed. After the installation has finished successfully, you can make your first steps in the hand-shake™ system.

3.3.2 Update

When handshake™ is launched via Internet Explorer within a lo-cal intranet environment, the version installed on the workstation is compared with the version residing on the server. If the version on the workstation is older, you will be prompted to restart Setup.

To do so, run Setup and select Open to initiate the software up-date, and then follow the installation steps.

Fig. 2: Setup

Fig. 3: Update information



Once the installation has finished, close Internet Explorer and re-boot. This completes the Setup.

3.3.3 Logout

If you work with more than one client, you need to Logout to se-lect a different client.

After 20 minutes idle time (session timeout of the Internet Ex-plorer), handshake™ explorer will log you out automatically.

3.3.4 Login

If more than one client is established, the user can select the re-quired client. While there is no configuration data, a standard cli-ent (No Client Set) and a user is preset. To change client details and assign permissions (roles) to the users (including administra-tors), the logged-on user must have domain administrator rights. This Windows-specific access authorization is required for modi-fying existing user and client records.

Fig. 4: Update

Fig. 5: Logout

Fig. 6: Client selection


Boot-up and installation 3.3


3.3.5 Synchronize

The synchronization process is the distribution of the configura-tion data through the access manager to the checkpoints. The current configuration data of the checkpoint is compared with the new data, and reloaded if necessary.

Important: Each change in the configuration has to be syn-chronized!

To be able to execute a synchronisation, the logged on user must have the following user role:

local administrator right or user role event location manager or user role events manager

During the synchronization process the progress is shown. The following parts are sent:

Checkengine configuration – ticket check logic Access Manager configuration – connection between check-

points and the handshake™ Server Data for extended emergency mode – checks used in the

extended emergency mode Handheld configuration – the Handheld configuration is pre-

pared to be loaded into the Handheld Ticket Reader Applica-tion (Ticket check). Depending on the setting of the Handheld, the synchronisation is loaded automatically or requires manual interaction on the Handheld.

Events to Load the configuration – after sending the neces-sary data for the checkpoints, the data is refreshed on the checkpoints.

Fig. 7: Synchronisation



When the synchronization has finished successfully, a corre-sponding message is shown on the screen. This frame is closed automatically after a few seconds.

If an error occurs during the synchronization process, the error is shown. The synchronised data is stored on the harddisk using the handshake™ standard directory \program files\Handshake\Config.

This frame can only be closed with the OK button. The synchro-nization has to be repeated.

Fig. 8: Error on synchronising


Client, user and employee management 3.4


3.4 Client, user and employee management

A handshake™ system can be operated by one client or by more than one in parallel. Client management in handshake™ features the following options:

One or more client(s) share a venue; the client can administer one or more venue(s).

The events of the individual clients utilize the common access hardware (readers, computers ...). The events of the individual clients are completely independent of each other.

If more than one client works on the same system, the access configurations of the other clients must not be modified.

All transaction statistics can be viewed by the client operating the event.

Clients can use tickets from the same ticket system or tickets from producers of their choice.

In handshake™ client management is realized by client-dependent user management. In the handshake™ system there is an exact assignment of users to the clients they work for. A user can work for more than one client. To this end, users get an according assignment of their rights with different clients. How-ever, users can be restricted to one client as well.

handshake™ fully integrates the Microsoft Windows user admini-stration. Each user known to the Windows domain can get rights within handshake™. This avoids double user and password managements. Users blocked in Windows are automatically blocked in the handshake™ system also. handshake™ comes with predefined user rights. These user rights represent the vari-ous parts of the system for which rights can be granted to the user. In user management, these rights are assigned or removed.

When using the Soft Pinpad or Monitor application on the Hand-held Terminal, the users logs on as an employee. Employees must not be windows users. Predefined employee rights exist.

3 Handshake.Logic – Explorer 3.4 Client, user and employee management


3.4.1 Client administration

Basic information on a client consists of name and description. When installing handshake™ one user named "No Client Set" is setup automatically.

Using the Client number the import date from the ticketing sys-tem is assigned to the client. This number is shown in ascending order and is an important parameter for the ticketing partner.

To modify and adjust a client’s information, Edit client (I) is se-lected.

To enter information regarding a new client, New Client ( ) is selected. Then, users who need to be granted program rights for the client, are assigned. Assigned users are granted the standard profile "User Manager". Users with this right can enter, modify and delete users and assign rights to these users. Only users with “Partner Service” privileges are allowed to modify, delete and create client records.

For displaying detail information on the client, the underlined cli-ent name (link) has to be clicked.

Pay attention to the navigation bar at the bottom. It indicates the level of details displayed. To return to the client, click Clients.

Fig. 9: Client administration

Fig. 10: Client information detail




3.4.2 User administration

Any Windows user registered on the local intranet may be as-signed a right (permission profile).

Basic user details comprise the user’s name and designated do-main (User name) and the full name of the user. These details are imported from Windows’ user administration and can there-fore be modified only by way of the Windows user administration application.

3.4.2.1 Assign new user

Important: To add new user records within the local intranet environment you must use Windows’ user administration tool.

To allocate rights to a user of the selected client, select New User (*).

Fig. 11: User

Fig. 12: New user



User rights are assigned in accordance with operators responsi-bilities. Next, select the required rights from the list and assign it using the > button (>> select all roles) then hit the OK button.

To select a user from another intranet domain, choose Selec-tion….

Selecting a different domain name will bring up the list of users allocated to this domain. Select the desired user entry and hit OK to confirm your selection.

Fig. 13: Select user from domain

Tab. 1: Available user rights

User right Description of permissions Partner Service Special access privileges; reserved for SKIDATA™ sales and service

partners User Manager Administration of user records Partner Manager Administration of ticket systems, ticket properties and imports Event Location Manager Administration of event venue profiles, access control units, access

permissions and actions Events Manager Administration of events, permissions and conditions

Report Manager Permission to use the handshake™ Reporter and to create the admis-sion statistics (Admission statistics, Visitor frequency analysis, length of stay).

Special Report Manager Permission to use the handshake™ Reporter and to create the irregu-larities statistics (Irregularities, Ticket Data).




The assigned user rights will be available the next time the user in question launches handshake™.

3.4.2.2 Modify user right

To modify and adjust a user’s information, and to assign rights to a user, Edit user (I) is selected. Depending on their tasks the required rights are assigned to the users.

The user detail information displays for which clients rights are assigned to the user.

Information: If user rights are altered, the user must log out and back in for them to take effect.

Tab. 2: Available user rights

User right Description of permissions Passive monitoring and messaging Running SKIDATA Monitor (passive role) and using the module hand-

shake™ Messaging Active Monitoring Running SKIDATA Monitor and executing system control functions

(e.g., manual turnstile release – i.e., active role) Archive Manager Permission to carry out data archiving tasks Archive User Granted read-only access to archive files Journal Permission to use the journal

Fig. 14: User roles assigned to user



3.4.3 Employee administration

Employees are set up to be able to log on to the Soft Pinpad or Handheld Monitor application on the Handheld Terminal. Em-ployees are no windows user by default, and can only logon to the handshake™ Handheld applications. For further detailed in-formation about the Soft Pinpad see manual handshake™ Soft Pinpad. An employee can be a handshake™ user as well.

A list of employees can be imported by means of an XML file sent through the interface. Employees registered may be assigned a role (permission profile). Depending on the assigned role, certain functions are available after login onto the handshake™ Hand-held applications.

More information about Soft Pinpad and Handheld Monitor can be found within the according user manuals.

3.4.3.1 New employee

To add an employee to the selected client, select New Employee (*), to edit an already existing employee select Edit (I).

Fig. 15: Employee administration

Fig. 16: Add / edit employee




The Employee name is keyed in at the Soft Pinpad the Full em-ployee name is used to identify the employee within reports.

The Password should consist of min. 4 characters. If the em-ployee is a handshake™ user at the same time, the name of the Handshake user has to be selected.

Marking the Blocked tag, will block the employee from login on to the handshake™ Handheld Applications.

User rights are assigned in accordance with the operators re-sponsibilities. Next, select the required rights from the list and as-sign them using the > button then hit the OK button.

Information: when using the Handheld Terminals as a checkpoint (ticket check using the Handheld Ticket Reader Application) the user must not be set up as an employee. There is no login procedure for the Handheld Ticket Reader Application.

Tab. 3: Available employee rights

Right Description Soft Pinpad usage User can login and execute all available control functions on the Soft

Pinpad. Administrator User can login, execute all available control functions on the Soft Pin-

pad, change the layout, exit from the Soft Pinpad Application and exit to the operating system.

Monitor usage User can login and open the SKIDATA Monitor (passive role) Monitor device control User can login and open the SKIDATA Monitor, execute all available

control functions and exit to the operating system (active role)

3 Handshake.Logic – Explorer 3.5 Venue administration


3.5 Venue administration

The physical characteristics of the event venue are defined as a logical scheme processable by the system.

handshake™ uses the following terms and concepts for this pur-pose:

3.5.1 Overviews

3.5.1.1 Global overview

The Global Overview shows the individual parts of the overall system.

The Event Venue is the highest-level item at the top of the hierar-chy. It may consist of one or more Layouts, which may in turn be subdivided into Areas. Gates represent groupings of checkpoints and are allocated to Areas.

Note that the Global Overview will only be available once the in-dividual parts have been set up.

Tab. 4: Definition of terms

Term Definition Venue The venue is the representation of the external characteristics. More than

one venue can be administered. Tickets of visitors proceeding from one venue to the other are not checked.

Layout The layout groups one or more areas into a logical access concept. The layout can be reused from event to event.

Area An area can be accessed and/or left through one or more gates. The area is the smallest part of a venue access control can be applied to.

Gate A gate is a group of checkpoints. Gates are assigned to an area. Checkpoint A checkpoint consists of a device for ticket control (e.g. turnstile with ticket

reader, Handheld). The central task of a checkpoint is to check and verify electronically readable tickets, grant access if the ticket is valid or refuse admission if it is not.


Venue administration 3.5


3.5.1.2 Checkpoint usage

This overview shows multiple allocations of individual check-points.

There may be several layouts defined for the event venue. Lay-outs are intended for easy switching between different system settings (e.g., Layout for access configuration “Football Game”, Layout for access configuration “Open-Air Concert”).

The use of multiple layouts may lead to the same checkpoint be-ing allocated to more than one layout.

Fig. 17: Global overview



3.5.2 Event venue

The venue describes the largest unit that will be administered in handshake™. Access is controlled within the venue.

For the venues controlled by the system, separate reports can be generated.

The used hardware (checkpoints) is assigned and managed in Layouts.

3.5.2.1 Event venue upper limit

For each venue the upper limit of possible capacity can be de-fined. The given value influences the counters shown. These val-ues are also displayed within the SKIDATA Monitor. The handshake™ Reporter provides a separate report, showing the number of people related to the upper limit (see chapter 4 Re-porter).

The value for the upper limit can be defined, while setting up a new venue and can be edited for already existing ones.

Fig. 18: Checkpoint usage

Fig. 19: Venue




When setting a value for the upper limit, it will be shown within the SKIDATA Monitor and handshake™ Reporter. The system counter is used to display the fill limit within the SKIDATA Monitor e.g. 45 / 2000, and to be able to start the fill level reports.

On activating the upper limit, the checkpoint will be blocked on reaching the set value. These settings can be changed at the system counters (see 3.8.9 System counter).

3.5.2.2 Checkpoint default behaviour

When setting up the event venue, you can define the standard behaviour of checkpoints. This behaviour will apply to all check-points throughout the venue. If no default behaviour is set, the standard display text shows the name of the area and the light signal of the corresponding checkpoint mode.

When the checkpoints are working in offline mode, the light signal for entry/exit direction checkpoint mode "Ticket Check" and the Display text for entry/exit direction checkpoint mode "Ticket Check" are used. For all other checkpoint modes the standard text and light signal will be used (when AS x70i CF/V2 is used).

Fig. 20: Upper limit



Please note that the checkpoint standard behaviour has to be set for entry and exit direction and for each of the five possible oper-ating modes of the checkpoint. To set up a new display text, click on the New button and select the operating mode for entry or exit and insert the display text. Therefore you can define the display text for the following modes (max. 16 characters):

Display text entry direction checkpoint mode „Ticket Check“ Standard text "Name of Area"

Display text exit direction checkpoint mode „Ticket Check“ Standard text "Exit"

Display text entry direction checkpoint mode „Free Passage“ Standard text FREE PASSAGE

Display text exit checkpoint mode „Free Passage“ Standard text FREE PASSAGE

Display text entry direction checkpoint mode „Permanent open“ Standard text FREE PASSAGE

Display text exit direction checkpoint mode „Permanent open“ Standard text FREE PASSAGE

Display text entry direction checkpoint mode „Blocking“ Standard text NO ENTRY

Display text exit direction checkpoint mode „Blocking“ Standard text NO EXIT

Display text entry/exit direction checkpoint mode "Out of Service" Standard text OUT OF SERVICE

Fig. 21: Checkpoint default be-haviour




To set up a new light signal, click on the New button and select the operating mode for entry or exit and select the light signal from the list.

light signal entry direction checkpoint mode „Ticket Check“ standard light signal "red"

light signal exit direction checkpoint mode „Ticket Check“ standard light signal "red"

light signal entry direction checkpoint mode „Permanent open“ standard light signal "green"

light signal exit direction checkpoint mode „ Permanent open “ standard light signal "green"

light signal entry direction checkpoint mode „Free Passage“ standard light signal "green"

light signal exit direction checkpoint mode „Free Passage“ standard light signal "green"

light signal entry direction checkpoint mode „Blocking“ standard light signal "red"

light signal exit direction checkpoint mode „Blocking“ standard light signal "red"

light signal entry/exit direction checkpoint mode "Out of Service" standard light signal "off"

The following light signals are available

No light signal green light signal flashing green light signal red light signal flashing red light signal red and green flashing synchronously red and green flashing alternately yellow light signal (3-lights) yellow flashing light signal (3-lights)



Fig. 22: Checkpoint display and light signal




3.5.3 Layout

A layout groups one or more areas into a logical access concept. Layouts are designed to allow for hardware to be used in different configurations.

Any checkpoint that is not allocated to a layout will automatically be set to “Out of Service” mode. Checkpoints allocated to multi-ple layouts are displayed in a separate list (see 0 Checkpoint us-age).

Only one layout is activated at the moment. Note that this does not apply to layouts with different checkpoints; here multiple lay-outs may be active at the same time. The currently active layout is indicated by a symbol next to its name. For not active lay-outs the symbol is shown.

The validity of the layout is defined through a certain time. That means that the layout is activated at a certain moment (day and hour). The time for activation can be set up directly when defining the layout, or when an event is set up (see 3.8.2 Events).

Note: If only one layout is set up, this layout will always stay active and does not need a time for activation.

Fig. 23: Event venue with two layouts



When setting up the activation time using the button New Time, the symbol for this time is a green light bulb . When the activa-tion time for the layout is set through an event a red light bulb is shown. To change a used time, it has to be removed from the used time specification list on the right side, using the < button. The time is shown in the list of the available time specifications and can be edited using the button Edit Time.

Note: Activation time set through the Event (red light bulb), can only be changed through the event (see 3.8.2 Events)!

Fig. 24: Layout properties dia-logue

Fig. 25: Edit the time




3.5.3.1 Copy layout

To take over an existing layout with its assigned areas, gates and checkpoints, the whole layout can be copied. By clicking on the copy symbol an information dialog is shown, where the name for the new layout is inserted.

Select the layout to be copied and insert the Name and the De-scription for the new layout. Click on the Execute button to start the copy process. The Progress information shows the success-ful finish of the copy process.

3.5.4 Areas

An area can be accessed and/or left through one or more gates. The area is the smallest part of a venue access control can be applied to. Areas are created within layouts. The gates and there-fore the checkpoints constitute the interfaces between areas.

For each area the upper limit of possible capacity can be defined. The given value influences the counters shown. These values are also displayed within the SKIDATA Monitor. The handshake™ Reporter provides a separate report, showing the number of peo-ple related to the upper limit (see chapter 4 Reporter).

Fig. 26: Copy layout



The value for the upper limit can be defined, while setting up a new area and can be edited for already existing ones.

When setting a value for the upper limit, it will be shown within the SKIDATA Monitor and handshake™ Reporter. The system counter is used to display the fill limit within the SKIDATA Monitor e.g. 45 / 2000, and to be able to start the fill level reports.

On activating the upper limit, the checkpoint will be blocked on reaching the set value. These settings can be changed at the system counters (see 3.8.9 System counter).

3.5.5 Gate

A gate is a group of checkpoints. Gates are assigned to an area. For each gate, and therefore for the individual checkpoints, you select whether the assigned checkpoints act as entrance, exit, or transition.

Fig. 27: Areas

Fig. 28: Upper limit




A gate must get the following properties:

Both Name (30 characters) and Description should describe the gate, thus enhancing recognizability for future uses (e.g. reports).

Fig. 29: Gates

Fig. 30: Gate



If the gate is an entrance - Entry or Exit, the assigned check-points must lead into (To:) or out of an area (From:). This means that in the ticket inspection, validity in that area can be checked.

If the gate constitutes a cross-over (Transit) from one area into another, the From: – To: transition must be selected.

The Available checkpoints are displayed and can be assigned to the gate using the assignment arrows >. Checkpoints already assigned, will show the name of the gate as additional informa-tion.

Note: You should always create the checkpoints before creat-ing gates. This way, you will be presented with a list of avail-able checkpoints for easy selection.

The Gate direction is configured for normal passage direction by default. By reverting (reverse) the reader orientation, a gate can be converted from an access gate to an exit gate (and vice versa). An important parameter dependent on the reader orienta-tion is the turnstile direction.

When Informative check on handhelds is activated at the gate, the Handheld Terminals assigned to this gate will not execute a ticket check but read the properties of the scanned ticket an dis-play them in the ticket reader application. A basic ticket check is executed, the ticket is not validated.

Fig. 31: Gate direction




3.5.6 Checkpoints

A checkpoint consists of a device for ticket control (e.g. turnstile with ticket reader, Handheld). The central task of a checkpoint is to check and verify electronically readable tickets, grant access if the ticket is valid or refuse admission if it is not. The following reader and barrier devices are supported:

Reader type No reader (counting turnstile) Reader AS x70i CF (via Arcnet or Ethernet) Reader AS x70i CF/V2 (via Arcnet or Ethernet) Two way reader AS x70i CF/V2 (via Ethernet) OBID-classic-pro (door opener) Column AS450 (via Arcnet) KeyDetector DUO (serial/Ethernet converter connection) Handheld Terminal AS x70i HH (WLAN connection)

Barrier type No Barrier Turnstile SKIDATA™ DKZ x70i Turnstile SKIDATA™ ADA Generic turnstile (with SD676) via Reader I/O Broughton (with SD676) Gotschlich (with SD676) Kaba Gallenschütz (with SD676) Scheidt & Bachmann (with SD676)

3.5.7 General

Required checkpoint configuration properties:

Fig. 32: Checkpoint properties



The Reader Type of the checkpoint has to be selected when set-ting up a new checkpoint. It identifies the device model. The reader type cannot be changed after it has been saved.

Reader AS x70i CF/V2 can read barcode tickets and contact-less data carriers; it can be controlled by way of an Ethernet or Arcnet line. Depending on the equipment contactless data mediums with frequencies 125 kHz (Keycard, Wristbands), 13 MHz, ISO 15693 (Keycard ISO, Keycard ISO DUAL, Infineon), ISO 14443 (Mifare) can be scanned.

Reader AS x70i CF can read barcode tickets and contactless data carriers; it can be controlled by way of an Ethernet or Arcnet line. Contactless data mediums with frequencies 125 kHz (Keycard, Wristbands) and 13 MHz can be read.

Two way reader AS x70i CF/V2 (via Ethernet), two readers AS x70i CF/V2 are mounted on one turnstile, one reader will work as master the other as slave. The communication be-tween the two readers is done through the network.

OBID-classic pro reads exclusively contactless data medium ISO Format 14443.

Parking Column AS450 can read barcode tickets and con-tactless data carriers with frequencies 125 kHz (Keycard, Wristbands); it can be integrated into the system only by way of an Arcnet connection.

KeyDetector DUO is used for reading contactless data carri-ers with frequencies 125 kHz (Keycard, Wristbands) and 13 MHz; it is controlled by way of the serial/Ethernet converter. The KeyDetector will open a contact for controlling a door ac-tuator, barrier or turnstile.

Handheld Terminal AS x70i HH supports reading of tickets with visible barcodes and contactless data mediums. The ter-minal is integrated into the system network via the Wireless LAN (WLAN). Using the PPT2800 and Keycore module 125 kHz (Keycard, Wristbands) and 13 MHz can be read. Using the PPT8800 and RFID Module 125 kHz (Keycard, Wrist-bands), 13 MHz, ISO 15693 (Keycard ISO, Keycard ISO DUAL, Infineon), ISO 14443 (Mifare) can be read.

To enable the handshake™ system to identify the location and hardware configuration of a checkpoint, applicable hardware properties, as well as a device Name (30 characters) and De-scription must be specified on the In general tab.

The Access Manager (Managed by) can be installed on a sepa-rate PC or on the server. It controls a defined number of check-points depending on the cabling situation. The checkpoints are directly integrated in the local area network.




The Barrier type parameter identifies the barrier device used. The following options are available:

No Barrier Turnstile SKIDATA™ DKZ x70i Turnstile SKIDATA™ ADA Generic turnstile (with SD676) via Reader I/O Broughton (with SD676) Gotschlich (with SD676) Kaba Gallenschütz (with SD676) Scheidt & Bachmann (with SD676)

Depending on the barrier a passage timeout can be specified (in seconds). If the Reader fails to receive a “close” signal from the barrier within the pre-set passage timeout, the passage can be counted (Count passage) or not counted and the turnstile is set back to the starting position (Revoke passage).

Out-of-Service behaviour determines the behaviour of the gate in the event the checkpoint is set temporary to "Not available", or is in the checkpoint mode "Out of Service". Two possible settings are available: Free Passage and Blocked. An off-line situation is not the same as an out-of-service operation. The checkpoint has no server connection when in off-line mode.



3.5.8 Reader parameter

3.5.8.1 Configuring reader type AS x70i CF / AS x70i CF/V2

Depending on the type of network connection (Arcnet or Ethernet), enter an Arcnet or IP-address in the corresponding in-put box. Each Arcnet-based checkpoint administered by way of the same Access Manager is identified by its own unique Arcnet Address 1 to 8 (depending on the reader model used, this ad-dress must also be set physically at individual checkpoints). The IP-address must be specified in the appropriate input box. When the reader is powered up, its IP address is detected either by way of an integrated DIP switch or via a DHCP server or by the help of a keyboard plugged in at the reader.

The Equipment flag is set automatically; it describes the stan-dard hardware configuration. The Firmware version and BLL firmware version identify the version of the device control soft-ware; these are filled in automatically. In the case the firmware needs to be updated, the update process is started automatically.

Backlight time lets you specify the time that the display should remain lit after a reader transaction has been completed. The checkpoint can be equipped with a 3-Colour Traffic Signal (red/yellow/green). It can be activated using the option 3-colour-lamp. When using an Ethernet-based reader, the Default Port 5000 is set. If necessary you can specify a different value.

The Firmware Version for the Feig module is not in use at the moment.

Fig. 33: Reader type AS x70i CF / AS x70i CF/V2




3.5.8.2 Configuring reader type two way reader AS x70i CF/V2

Two readers AS x70i CF/V2 are mounted on one turnstile DKZ x70i of ADA turnstile and are defined as one checkpoint. Using this configuration, one turnstile can be used for entry and exit at the same time.

One reader will be defined as master the other as slave. The communication between the two readers is done through the network and does not require any further hardware components. The master reader assigned to a entry- or exit gate is responsible for the direction in which the turnstile will be opened. The slave gets the opposite direction automatically.

Fig. 34: Feig module



The IP-address must be specified at the Master and the Slave reader by the help of a keyboard plugged in at the reader.

The Equipment flag is set automatically; it describes the stan-dard hardware configuration. The Firmware version and BLL firmware version identify the version of the device control soft-ware; these are filled in automatically. In the case the firmware needs to be updated, the update process is started automatically.

Backlight time lets you specify the time that the display should remain lit after a reader transaction has been completed. The checkpoint can be equipped with a 3-Colour Traffic Signal (red/yellow/green). It can be activated using the option 3-colour-lamp. When using an Ethernet-based reader, the Default Port 5000 is set. If necessary you can specify a different value.

The Firmware Version for the Feig module is not in use at the moment.

Fig. 35: Configuring reader type two way reader AS x70i CF/V2




3.5.8.3 Configuring reader type OBID-classic-pro

The OBID-classic pro door opener reads exclusively contactless data medium ISO Format 14443.

The OBID-classic-pro is connected by way of serial interface or through IP adress.

The Port parameter identifies the appropriate IP-port to which it is connected. When using a MOXA, serial connection to a se-rial/Ethernet converter, the Port defines the serial connection port.

Fig. 36: Configuring OBID-classic-pro



3.5.8.4 Configuring parking column AS450

The Arcnet-Address must be unique for each column connected to the same access manager. This address must also be set physically at individual column.

Firmware version identifies the version of the device control software; this is filled in automatically. The Equipment flag must be set to “Default” to allow for proper detection of the check-point’s hardware configuration.

Backlight time lets you specify the time that the display should remain lit after a reader transaction has been completed.

If Presence required is activated, tickets will only be checked if the presence of a vehicle is detected via the induction loops. If no presence detection loops are installed, this option will be dis-abled. If this option is deactivated although a presence detection loop is installed, the vehicle presence signal of the loop will be ignored.

Retain ticket lets you specify if paper tickets used for the exit should be retained and collected in a bin inside the column. Plas-tic tickets (Keycards™) will not be retained.

Fig. 37: Parking column AS450




3.5.8.5 Configuring reader type KeyDetector DUO

KeyDetector DUO is connected by way of serial interface or through IP adress.

The Port parameter identifies the appropriate IP-port to which it is connected. When using a MOXA, serial connection to a se-rial/Ethernet converter, the Port defines the serial connection port.

Firmware version indicates the version number of the device software; this is filled in automatically.

Fig. 38: KeyDetector DUO



3.5.8.6 Configuring reader type Handheld Terminal AS x70i HH

Each Handheld Terminal is assigned its own fixed IP-address, which is filled in automatically. The Machine name refers to name of the Handheld Terminal. This name is put in directly at the Handheld Terminal.

The BLL Firmware Version identifies the software version of the R/F reading module plugged in at the Handheld Terminal and is filled in automatically for information only.

To prevent the possibility to exit from the Handheld Ticket Reader Application to the operating system, you can set a Handheld password (maximum 4 numeric digits). The Handheld Terminal is allocated to a certain gate. If the Allow change of gate box is checked, the Handheld can also be used with other gates.

Note: The Ticket Reader Application is used for ticket control and at the same time as Access Manager for the Handheld Terminal. It is not necessary to set up an Access Manager, as this is done automatically by the handshake™ Explorer. Note that this Access Manager has the same name as the device.

Fig. 39: Handheld Terminal ASx70i HH




3.5.8.7 Handheld interface

To be able to request ticket details via the Handheld Ticket Reader Application or Soft Pinpad, it is necessary to set up a socket-based interface.

Note: The recommended standard port 6000 is set fort he ti-cket inquiry at the Ticket reader application and is also used for the ticket inquiry within the Soft Pinpad.

Note: The interface can be part of any ticket system in use. The Issuer (Id) of the ticket system and the Port (Information Port) have to be put in at the server settings of the Handheld Ticket Reader Application!

Please find further information on how to use the Handheld Ter-minal in the Ticket Reader Application manual.

Fig. 40: Handheld interface



3.5.9 Barrier parameters

3.5.9.1 Configuring turnstile SKIDATA™ DKZ x70i

Especially in times of massive visitor influx, the Barrier behavior concerning pitch movement and the sensor behaviour are deter-mining factors. SKIDATA™ strongly suggests turning both the pitch-movement angle and the sensor on. Pitch movement on means that the turnstile drum is advanced by approx. 10° to indi-cate to the user that (s)he may pass through the gate. If the Sen-sor is on, the movement of visitors passing through the gate is detected and the turnstile arm is advanced by a full position to grant admission.

The Firmware version identifies the version of the device control software; this is filled in automatically.

The Turnstile Rotation parameter determines the direction (right or left) in which the turnstile arms revolve (see Fig. 31: Gate di-rection).

When the SKIDATA™ DKZ x70i is equipped with the panic es-cape mechanism (foldable star), the setting for the Emergency escape support has to be activated, so in an emergency situa-tion the panic mechanism can be released through the SKIDATA Monitor (relay switch required).

Fig. 41: SKIDATA™ DKZ x70i




3.5.9.2 Configuring SKIDATA™ ADA turnstile

The ADA turnstile is used as barrier for entries where wheel-chairs, trolleys etc. are leaded into the venue. The single star of the turnstile is down folded in emergency mode.

The setting for the Rotation mode can be set to half-rotation two times or Full rotation.

half-rotation two times will move the arm after the sensor registers the passage from horizontal to vertical position (180° rotation), following the passage and after the defined waiting period after passage the arm will move back into start posi-tion in reversed direction.

The Full rotation will move the arm after the sensor registers the passage from horizontal to vertical position (180° rotation), following the passage and after the defined waiting period af-ter passage the arm will move back into start position.

The Barrier behaviour will bring the arm into the vertical posi-tion, the sensor is active.

Firmware Version identifies the version of the device control software; this is filled in automatically.

Fig. 42: SKIDATA™ ADA turn-stile



The Turnstile Rotation parameter determines the direction (right or left) in which the turnstile arms revolve (see Fig. 31: Gate di-rection). The Signal tone on permanent open will indicate that the turnstile is positioned in vertical position. The delay time un-til the signal tone is played can be defined in seconds. The Waiting period after turnstile stops is used in case the sensor detects a person while the arm is closed, e.g. the person stays in the entry area to long. The arm will stop immediately and will be closed after the set waiting period is over.

The setting for the Emergency escape support has to be acti-vated, so in an emergency situation the arm can be folded down using the SKIDATA Monitor (relay switch required).

3.5.9.3 Generic turnstile (with SD676)

When the circuit board SD676 is in use, third party barriers can be attached to the reader.

The Firmware version indicates the version number of the con-trol board SD676 and is filled in automatically.

The Release Mode defines the type signal that is sent to the third party barrier to open the barrier (Release and direction, release left – release right). The Type of signal defines the signal type

Fig. 43: Configuring a generic turnstile




sent to the third party barrier to open the barrier (Pulse or steady signal). When selecting type of signal pulse, the Length of the pulse can be defined in milliseconds.

The Feedback of the hardware (Mode) can be set to no feed-back, passage only, passage and direction, passage left – pas-sage right.


Depending on the third-party barrier, a Bidirectional operation supported (entry/exit) and the mode for Permanent release supported can be used. When these settings are activated, the direction switch and the change of the operation mode can be used within the SKIDATA Monitor.

The Extended settings contain detailed definitions of the signals for the third party barrier.

Fig. 44: Extended turnstile pa-rameter



3.5.9.4 Via reader I/O

When no control board SD676 is in use to connect third party barriers the connection is made through a SIO contact.

Setting the Mode defines the way of sending a release to the bar-rier (Release and direction, Release left – Release right).

The Type of signal defines how the release signal is sent to the barrier (Pulse, steady signal). When the signal type is pulse, the Length of the pulse can be set in milliseconds.



Fig. 45: Via reader I/O




3.5.9.5 Third party barrier (with SD676)




3.5.9.6 Counting turnstile DKZ x70i

The SKIDATA™ turnstile DKZ x70i can be used as barrier with counting functionality. handshake™ communicates through an own IP-Address with the turnstile without reader. The turnstile must be configured like a regular checkpoint. Passages are re-corded without ticket check.

The reader type No reader must be selected.

Fig. 46: Third party barrier



Pitch movement on means that the turnstile drum is advanced by approx. 10° to indicate to the user that (s)he may pass through the gate. If the Sensor is on, the movement of visitors passing through the gate is detected and the turnstile arm is advanced by a full position to grant admission.



The counting turnstile is recognized through the Lantronix device located on the control board SD676. With the help of the Lan-tronix XPort Device Installer Tools, a valid IP-address for the turnstile is set. The value for the default Port is 5000. If neces-sary another port number can be used.

Fig. 47: Counting turnstile




3.5.9.7 Configuring barrier type AS 450 ASL

When using the Column AS450, the barrier type is automatically the Barrier AS450 ASL.

Firmware version identifies the version of the device control software; this is filled in automatically. Loop Mode lets you spec-ify which of the following four basic gate arrangements applies to the gate in question: Direction specifies whether the parking col-umn is used to control entry or exit, i.e. whether the checkpoint is an entrance or exit.

Fig. 48: Barrier type AS 450 ASL

Fig. 49: Loop mode



Default Entry/Exit gate When set to this mode, the system will detect a passage when the barrier loop is deactivated following activation of the presence detection loop. Normally, the parking customer drives over the presence detection loop, stops at the en-trance terminal to insert a permit card or take a ticket, then drives on into the garage, thereby activating and subse-quently deactivating the barrier loop. At that point, the gate passage transaction is complete and the barrier closes.

Default direction loop refers to an induction loop located on the other side of the gate, relative to the side of the gate being approached. Together with the induction loop located beneath the barrier, this loop functions as a passage direction detector. In this scenario, both the barrier loop and direction loop must be activated and subsequently deactivated in the correct se-quence (i.e., barrier loop barrier loop & direction loop di-rection loop passage complete).

Extended direction loop In this arrangement, the direction loop is located between the presence detection loop and the barrier loop. Here it is not used to detect the direction in which a vehicle passes through, but rather to cut out the passage timeout on the relatively long way from the presence detection loop to the barrier loop. This configuration is particularly useful in arrangements where the parking column and barrier are placed at a large distance rela-tive to each other. The special loop in this case prevents the passage timeout from elapsing in case a vehicle moves too slowly towards the barrier loop.

Double presence detection loop In this configuration, the parking column will only be activated when both loops (PDL and PDL2) are activated at the same time. This is to prevent fraudulent egress attempts, e.g. get-ting a ticket at an entrance gate by using a shopping or lug-gage trolley to simulate a vehicle, and using this ticket to leave the garage within the in-out grace period to avoid paying for the actual stay.

3.5.10 Modes

The checkpoint modes can alternatively be set in the checkpoint modes menu (see 3.5.13 Checkpoint modes).




3.5.11 Copy checkpoints

To ease the set up of checkpoints an already defined checkpoint can be multiplied. Click on the copy symbol to open the copy frame where the template checkpoint is selected.

Select the Checkpoint to copy from the available checkpoint list. Depending on the selected checkpoint type the other settings are displayed. Select the Number of copies that you intend to create and insert the Name for the first checkpoint. As soon as the Exe-cute button is clicked the number of checkpoints is created. If the Name of the checkpoint includes a number, this number is in-creased by the number of created copies. (e.g. CP East 2, CP East 3 to CP East 11).

Depending on the selected Checkpoint to copy (AS x70i CF/V2, KD, Handheld etc.) an IP-address or Port has to be inserted. During the copy process those values will be increased for each copied checkpoint.

Fig. 50: Copy checkpoint



When copying AS x70i CF checkpoints, the port can be used in-stead of the IP-address (IP address stays the same – port will be numbered) this means that the IP-address will be the same for all checkpoints but the port will be increased.

In order to take over the layout/area/gate assignment of the Checkpoint to copy to the new checkpoints, the Copy assign-ment for current client only is selected.

In the case of multi-client management, the Copy gate assign-ment for all clients can be selected, and the assignment for all clients will be automatically taken over.

When selecting Copy checkpoint modes all defined checkpoint modes of the Checkpoint to copy are used for the new created checkpoints.

3.5.12 Access Manager

Each checkpoint is connected through the Access Manager to the handshake™ network. Depending on the number of con-nected checkpoints, the Access Manager Service is installed on a windows PC or directly on the server (<10 checkpoints).

When setting up the checkpoints they are connected to the cor-responding Access Manager (see 3.5.7 General). When editing the Access Manager the assigned checkpoints can be reas-signed.

Fig. 51: Access Manager




A Name (30 characters) and Description are given to identify the Access manager. The Machine name identifies the PC where the Access Manager Service is installed.

Note: The Handheld Terminal is an exception regarding the connection to the Access Manager. The Handheld Terminal is connected to the network through a WLAN connection, and thus not through an Access Manager Service.

Each Handheld Terminal is its own Access Manager shown in the list of the existing Access Managers.

The Access Manager User interface (GUI) is described in chapter 5 handshake™ – Access Manager.

3.5.13 Checkpoint modes

The set checkpoint modes function as a trigger to change the checking modes of the checkpoints at a defined point in time.

Checkpoint modes are used to configure the access control be-haviour of checkpoints in either access direction (depending on the possibilities of the barrier). The mode can be overruled manually using a control card directly at the checkpoint or execut-ing a command at the SKIDATA Monitor.

Fig. 52: Access Manager check-point assignment



In case checkpoints are assigned to multiple layouts, the check-point modes can be set individually for each layout.

Checkpoint modes are always set for entry and exit direction, even if the checkpoints are one direction devices. The check-points assume a predetermined behaviour from a certain date and time (=point in time) on. This behaviour remains valid until the next time a different checkpoint mode is activated. A check-point mode is never terminated but overwritten by a new mode.

Note: Checkpoints without checkpoint mode use the default behaviour Mode Ticket Check, light signal red.

3.5.13.1 New / edit checkpoint modes

In case more than one layout is available, the layout for which the checkpoint modes are set must be selected

On selecting the layout, the existing checkpoint modes are dis-played. When no modes are defined, the checkpoint will work in "Ticket check" mode for both directions.

To set up a new mode, click the new symbol. The edit an exist-ing checkpoint mode, double click the mode you want to change or select the mode and click the edit symbol.

Note: When deleting a checkpoint mode, it will be deleted ir-revocable for all checkpoints using the same mode.

When entering a new checkpoint mode, you have the option of defining a new period as well. An overview of the available peri-ods is given in the reader periods menu (see 3.6.1 Reader peri-ods).

Fig. 53: Select layout for checkpoint mode




Depending on the capabilities of the barrier, following modes for entry/exit direction are provided:

Unchanged – the last known mode is used. Ticket Check — Tickets are verified with respect to their va-

lidity; the turnstile is opened if the result is positive Free Passage — Guests may pass through the gate without

having to use a ticket; the display shows “Free Access” No Passage — The turnstile is locked, i.e. access through the

gate is denied; the display shows “No Access” Out of Service — The checkpoint reverts to the previously

defined ‘out of service’ behaviour (see 3.5.7 General). Permanent open – can only be used for ADA turnstiles, the

turnstile star is set to vertical position, until a control card or the Soft Pinpad resets the turnstile.

Fig. 54: Checkpoint mode



Entry direction Exit direction

Dark colours indicate the operating mode of entrance and light colours for exit readers.

Important: The direction of the readers can be reversed by changing the checkpoint operating mode. This way, an en-trance reader can be converted to an exit reader, and vice versa. The checkpoints can be reset to their standard direction by sending another checkpoint mode command (Switch Direc-tion).

Fig. 55: Checkpoint modes


Time periods 3.6


3.6 Time periods

3.6.1 Reader periods

Reader periods are the time mark definitions which can only be used for checkpoints. Reader periods must be defined when set-ting up checkpoint modes. Two standard reader periods, always and never are defined automatically. When defining a new reader period, you enter the start date and time. Next, specify the days of the week on which the reader period should be acti-vated. Unless you specify an end date, the reader period will re-main open-ended.

Note: When deleting a reader period still in use an information dialog about the dependencies will be shown!

In the reader periods, already expired periods are displayed as well. These can be deleted manually. You can delete all elapsed periods at once by clicking the symbol. Note that doing so will not affect the statistics.

Fig. 56: Reader periods

Fig. 57: Expired periods dialogue

3 Handshake.Logic – Explorer 3.6 Time periods


3.6.2 Regular periods

Regular periods are the definition of a from – to duration for which for instance access rights can be granted.

Regular periods are required for handshake™ access configura-tion.

Two standard reader periods, always and never are defined automatically.

The meaning of standard time periods has to be interpreted like: each day from Begin date (Begin time to End time) until End date. E.g. the activated time period is valid from 30.06.2006daily from 00:00:00 am to 23:59:59 pm including 15.09.2006.

Note: When deleting a regular period still in use an informa-tion dialog about the dependencies will be shown!

Regular Periods also shows expired periods; these may be de-leted. Note that doing so will not affect the statistics.

Regular periods can be deleted in the same way as reader peri-ods.

Note: Start and end times indicate the start and end minutes, respectively (e.g., start time 09:00:00, and end time 20:00:59).

Fig. 58: Regular periods


Ticketsystem configuration 3.7


3.7 Ticketsystem configuration

The Edit configuration comprises all settings for ticket handling at the checkpoints. In order to be able to accept tickets from one or more ticket systems (ticket producers) at the checkpoints, the ticket data need to be decoded in the handshake™ system.

In the handshake™ system, the following designations are used:

Fig. 59: Connection handshake™ – Ticket Partner


Designation Explanation Code Definition File – CDF The Code Definition File contains all required information for interpreting

the information electronically stored in the ticket in the handshake™ sys-tem.

Global property The global flag for the ticket property makes the property available for the configuration of other clients.

Interface Ticket systems can transmit data of various formats to the handshake™ system, depending on the configuration of the interface. The correspond-ing interface settings are required for the handshake™ Importer.

Blacklist The blacklist contains information about blocked tickets. This information is automatically adopted by the importer to the handshake™ system so these tickets can be rejected at the checkpoints.

3 Handshake.Logic – Explorer 3.7 Ticketsystem configuration


A CDF (Code Definition File), which needs to be coordinated be-tween SKIDATA AG and the ticketing partner and is installed, constitutes the basis for the verification of the ticket (barcode or contactless).

The ticket properties of the individual ticket types must be defined in the system once. T

3.7.1 System settings

Some extended functionality of handshake™ is de-/activated within the system settings.

3.7.1.1 Day change

When events take place over the midnight hours, the day change is set to the end of the midnight events. Doing so will extend the validity end for day tickets. The day change settings will influence the time period for events and for setting up checks.

3.7.1.2 Extended checks

The extended check offers the possibility to use the already inte-grated two step validation or to attach an additional instance to grant access via a plugin (see 3.7.9 Extended checks). The inte-gration of an additional instance to grant or deny access is done through the open and programmable Extend Check.Interface. It is used to implement additional ticket check criteria without having built in the handshake™ system.


Designation Explanation Whitelist The whitelist contains Information about tickets sold. This information is

automatically adopted by the importer to the handshake™ system so these tickets can be granted access at the checkpoints.

RF coding RF coding defines the different contactless coding technology, which are used by the ticket partners.

Emergency mode In case the connection between checkpoint and access manager is bro-ken, the checkpoint is working in emergency mode. Only basic system parameters defined in the CDF-settings are checked.

Extended emergency mode The extended emergency mode needs to be activated, in order to check additional properties coded in the barcode or chip during an emergency mode situation.

Ticket Properties (Properties) The ticket properties is the information coded in the barcode or transmit-ted to handshake™ via whitelist.




3.7.1.3 Extended emergency mode

The extended emergency mode is used to check ticket properties contained in the barcode or chip of the ticket if the checkpoint is not connected to the handshake™ server or access manager, and is running in emergency mode. Based on the ticket informa-tion within the barcode e.g. event number the tickets are granted or dismissed at the checkpoints (see 3.8.4.7 Extended emergen-cy mode).

To do the necessary changes, click on the edit symbol

3.7.2 Ticket system

The ticket system configuration distinguishes between an inter-face and the code definition files. A ticket system may use differ-ent interfaces and code definition files.

The selected Code Definition File influences the possible data medium and their coding.

In handshake™, ticket data is decoded by means of a Code Definition File (CDF). Based on this data, an ID number is calcu-lated, which is unique to each ticket. The properties of the ticket are used to determine the access permission.

Depending on its features and capabilities, a ticket system can transfer data of various formats to the handshake™ system via data interfaces.

Fig. 60: Edit system settings



Detailed information is shown within the Interface and the Code Definition Settings.

Note: A detailed list of the available ticket systems (CDF) can be found in chapter 9 Technical Terms, CDF – Code Definition File.

3.7.2.1 General

The General tab contains general ticket system properties.

The Name (30 characters) and the Description of ticket system can be chosen freely.

If a blacklist is provided, handshake™ will always perform a blacklist check when verifying a ticket. To enable this feature, ac-tivate the Blacklist available checkbox. The blacklist can be generated by the ticket system and imported into handshake™. Alternatively, it can be generated manually (see 3.8.11 Blacklist).

Fig. 61: Ticket system

Fig. 62: Ticket system




When setting up a ticket system available for more than one cli-ent, the activation of Other ticket systems are allowed to re-trieve data will allow the ticket system to inquire all ticket data independently from the client via Handheld or Interface.

3.7.2.2 Interfaces

The Ticket systems can transfer data to the handshake™ system in various formats, depending on the capability of the ticket sys-tem. The necessary data are transferred to handshake™ by way of the Importer (see Fig. 59: Connection handshake™ – Ticket Partner).

Using the interface the following data is transferred:

Whitelist (sold tickets) Blacklist (blocked tickets) ticket properties (codes of the single ticket types)

Data can also be requested by the ticket system or the Handheld application e.g. information about the read ticket.

Fig. 63: Interfaces



To edit interface settings, click on the Edit button.

A Name (30 characters) and Description of the interface can be entered as desired. The File Format, Version and Transmis-sion type parameters must be specified in accordance with the respective details agreed with the ticketing system partner.

Fig. 64: Interface definition

Fig. 65: File format and transmis-sion types




3.7.2.3 File format generic

File based for automatic file transfer via File System or FTP

3.7.2.4 File format XML

The XML (Extended Mark-up Language) interface is intended for file-based data exchange by file system, FTP or socket con-nection. XML is the standard interface for new ticketing partners. File transfer is performed in XML format (industry standard).

This interface works bi-directionally, i.e. the ticket system can transfer data to the handshake™ system, but it can also request information, which it receives through the same connection. Two basic types of request are supported: the simpler type consists of the request for details on the most recent use of a specific ticket; the complex request allows for the retrieval of detailed transac-tion information based on ticket specifics

XML supports multi-permissions means multiple access permis-sions on the same data carrier. One ticket (data medium) has ac-cess permissions for different events (e.g. season ticket). The multi permissions are updated through the interface, e.g. added or removed.

3.7.2.5 File format Nessie

Nessie is the standard interface by Ticketcorner for Ticketsoft and KART compliant Tickets. Note that Nessie can only be used with Ticketsoft and KART tickets and requires a socket connec-tion.

This interface works bi-directionally, i.e. the ticket system can transfer data to the handshake™ system, but it can also request information, which it receives through the same connection. Two basic types of request are supported: the simpler type consists of the request for details on the most recent use of a specific ticket; the complex request allows for the retrieval of detailed transac-tion information based on ticket specifics

The transfer protocols used for data exchange between Tick-etsoft and handshake™ are defined by Nessie

Note that this data interface supports only socket (online) connections

Generic (file-based) data transfer is not supported by Nessie



3.7.2.6 Keywords

The key words transmitted via the interface must be set up here. A red light bulb next to a keyword indicates that the correspond-ing ticket property is already in use and can therefore no longer be deleted. A green light bulb means that no ticket property uses this keyword.

E.g., if values for additional releases or display messages are to be transmitted as well, these must be defined here.

ADDRELEASES – determines the number of max. 3 addi-tional turnstile turns accessed with the ticket in question e.g. VIP Tickets – 1 Ticket = 3 persons. The additional releases are requested through the actions (see 3.8.5 Actions).

VALIDITY – this property specifies a validity period for the ticket, thus allowing a time-controlled access with the ticket in question. The transferred time detail is checked in the validity check (see 3.8.4.5 Validity check).

DISPLAYMESSAGE – allows for the display of customised messages at the checkpoint, these messages are requested through the actions (see 3.8.5 Actions).

OPERATORMESSAGE – allows for the display of customised messages at the checkpoint additional operator display, these messages are requested through the actions (see 3.8.5 Actions).

POINTS – defines the number of points for the ticket. The available points will be deducted depending on the access configuration on each use of the ticket (see 3.8.6 Point deduc-tion). The transferred value is also used for group tickets (e.g. 1 ticket = 23 passages (see 3.8.3.6 Groupticket)

Fig. 66: Interface keywords




DAYS – sends the number of valid days for the ticket (see 3.8.3.2 Day Ticket).

TIMETICKETPERIOD is used to determine the time period of a time ticket. The time period unit is given in minutes (see 3.8.3.5 Time-Based Ticket).

To configure the data transfer mode, insert the appropriate pa-rameter values in the respective Value fields.

3.7.2.7 Transmission type file system

Data transfer mode File System requires the following configura-tion settings:

Data and Archive directory (on server): These are required for handshake™ Importer. These directories may be specified as absolute or relative paths (e.g., c:\data or data\archive). Relative paths will be created as sub paths of the hand-shake™ installation directory. If a specified directory does not exist, it will be created automatically. The name of the file and archive directories must not be the same. Note that a sepa-rate import directory must be created for each ticketing sys-tem

interval specifies the time intervals at which the data supplied by the ticketing system should be processed by the hand-shake™ system; files will be processed immediately after be-ing stored in the file directory. For transmission type File System the recommended value for the interval is between 3 and 10 seconds.

Username and Password are required to access a directory on another PC (this parameter is optional)

3.7.2.8 Transmission type FTP

Data transfer mode FTP requires the following configuration set-tings:

IP Address and Port: These are required for establishing the data transfer connection. Standard port FTP-Port 21 is used.

Data and Archive directory (on the server): These are re-quired for the handshake™ Importer; note that these directo-ries must be specified in the form of absolute paths (e.g., c:\data; c:\data\archive); if a directory does not yet exist, it will be created automatically. Note that the name of the file and archive directories must not be the same. On the FTP server, the specified home directory is checked for new files; the response files are also stored in the server’s home directory. Note that a separate import directory must be created for each ticketing system.



Interval specifies the time intervals at which the data supplied by the ticketing system should be processed by the hand-shake™ system; files will be processed immediately after be-ing stored in the file directory. For transmission type FTP the recommended value for the interval is between 3 and 10 sec-onds.

Username and Password may be required to log on at the server, unless the connection uses anonymous login

3.7.2.9 Transmission type server / client socket

Data transfer mode Server or Client Socket (Nessie only) re-quires the following configuration settings:

IP Address or Port to be used for the connection (standard port 5000)

The Timeout interval is required for client/server socket con-figuration; if no data telegrams are received after the set time-out has elapsed, the connection is checked for possible faults (KeepAlive telegram); in case of problems the system will try to re-establish the connection. For transmission type Server Socket the recommended value for the Timeout is 300 sec-onds. Additional archive files should be set to Yes.

Depending on the send response setting, an according re-sponse is sent or not sent automatically to the ticket system part-ner for each import order. This response can be stored to the archive directory in file format.

Therefore the setting additional archive file is set to Yes or No. For transmission type File System and FTP the additional archive file has to be set to No, for Server / Client Socket to Yes.

When using the keyword ADDRELEASES to transfer the number of additional turnstile releases for group tickets, the setting of the flag Additional Releases act as Group Ticket is required. The ADDRELEASES is transferred to POINTS and can than be used for the group functionality.




3.7.3 Code definitions

Code Definition Files contain ticket structure definitions and are used for ticket verification at checkpoints. The values encoded on the ticket must be interpreted and processed correctly by the handshake™ system (access control and statistical evaluations). This is ensured by way of code definitions. The CDFs defined by SKIDATA™ in co-operation with the ticket system manufacturer are installed by handshake™ Setup for selection as required.

Click button Add to set up a new CDF or button Edit to edit the existing one.

3.7.3.1 General

The Code definition file is the existing CDF created in coopera-tion with SKIDAT AG and the Ticketing Partner.

A Name (30 characters) and Description of the code definition can be entered as desired.

Fig. 67: Code definitions



Emergency Behaviour determines whether or not inserted tick-ets are checked at the checkpoint in accordance with the coded CDF parameters when the checkpoint has no connection to the server or access manager. Emergency behaviour can be set to valid in both directions, for entry direction, and for exit direc-tion. A setting of invalid during emergency operation will pre-vent tickets from being accepted and validated at all.

The Execution priority defines the sequence for the ticket check. If more than 1 ticket system is in use, the ticket is checked against the Code Definition file with the lowest execution priority. The lowest value should be set for the most used ticket system.

The Whitelist represents an additional method of processing bar-code data. If the ticket system is capable of transmitting whitelist data, the Whitelist required option can be activated to take ad-vantage of this additional security check. When this option is acti-vated, any ticket read at a checkpoint must have a corresponding whitelist entry to be accepted. If this option is set to “No”, the system will also (but not exclusively) check tickets against the whitelist.

Fig. 68: Code definition




To load the set up checks to the checkpoints, the parameter Use in extended emergency mode is activated. When the emer-gency mode is activated no only the input parameters are checked but also, depending on the configuration, permits, condi-tions and denials (see 3.8.4 Checks), the properties used for the checks must be coded in the barcode or chip in order to be able to make an extended check.

To make a ticket system invalid for a certain time it can be deac-tivated and is not considered during the ticket check.

3.7.3.2 Input parameter

The input parameter specifies basic details about the ticket sys-tem, such as a unique identification number of the ticket system server, a unique installation number, etc. The name(s) of the in-put parameter depends on the selected CDF file. Optional No is the indicator of a compulsory value.

These values must be corresponding to the values used by the ticketing system. The input parameters are the basic parameters checked at the checkpoints during emergency mode and are loaded at the checkpoints.

Fig. 69: Code definition – input parameter



3.7.3.3 Keywords

The Keywords describe the electronic data on the ticket, ticket properties that are used by the handshake™ system as a basis for granting (or denying) admission at a checkpoint. A red light bulb next to a keyword indicates that the corresponding ticket property is already in use and can therefore no longer be deleted. A green light bulb means that no ticket property uses this key-word. Keywords coded in the barcode or chip can be used for extended emergency mode at the checkpoints.

3.7.4 RF coding

The supported Chip technology (contactless data medium) can be used or switched off. Depending on the selected CDF (see 3.7.3 Code definitions) the used RF coding variants for contact-less data medium are shown.

Fig. 70: Code definition keywords

Fig. 71: RF coding




The listed coding can be deactivated when not needed, for bene-fit of the reading speed of contactless data medium at the check-points.

The RF coding available in the CDF are listed and show a green light bulb when in use, and a red one when not used. Click on the button switch usage, to deactivate a certain RF coding.

Fig. 72: De-/Activate RF coding

Fig. 73: Devices and possible RF technology



3.7.5 Mifare conversion

The checkpoint types AS x70i CF/V2, OBID-classic-pro and the Handheld AS x70i HH88/WLAN with RFID module are able to read ISO 14443 data mediums.

Mifare Classic – consists of 16 sectors each with 4 Blocks, to enable the reading of the block data, a level key must be de-fined.

Mifare Ultralight – does not support level keys. My-d – supports simple and secure mode, handshake™ uses

the simple mode. CTS Secure – is a Mifare Ultralight data medium with the cor-

responding definition (CTS data medium only)

Prerequisite for the usage of Mifare data medium is the definition of those data mediums within the CDF file of the ticket system (see 3.7.3 Code definitions). When the usage of 14443 data me-diums is foreseen within the CDF, the additional tab folder for the settings of the Mifare sector data is displayed, when configuring the CDF Parameters. The configuration of the Mifare sector data can also be done using menu Mifare conversion.

Fig. 74: Mifare sector data




To allow Mifare data medium within the system some settings are necessary. The detailed information will be provided by the ticket-ing partner.

Insert a free definable Name for the data medium. To disable an already defined data medium it can be Deactivated the check-point will ignore the defined values.

Select the Accesstype and so the corresponding data medium from the list, after the selection further details have to be set.

Mifare Classic: on a sector Mifare Classic: using the Mifare application directory Mifare Ultralight: on a block

Fig. 75: Mifare sector data conversion

Fig. 76: Mifare sector data con-version



My-d: on a block CTS Secure

Depending on the Accesstype a Sector number / Application ID or Block number has to be inserted.

Sector number of the sector to read the Application ID is coded in the first sector and is compared

with the Application ID of the data medium, the logon to the sector is done through the level key

Block number of the block to read

In most cases the SKIDATA company number matches with the sector resp. block number and has to be the same as the input parameter of the corresponding CDF.

The Offset position defines the start position for the reading proc-ess. The Data length field defines the length of the data to read. When selecting Yes for Length integrated in the first byte after the Offset is considered as length definition for the data.

3.7.5.1 Configure Mifare security keys

When using data medium with level keys, those security keys ha-ve to be configured.

Fig. 77: Mifare security keys




The Mifare security key list shows the already defined security keys.

The security keys are stored encrypted within the database and are requested from Access Manager as well as from the Hand-held in an encrypted way.

To create a new security key click on the New button.

Insert a Name for the security key and select between Keytype Key A or Key B.

The Key itself has a length of 12 bytes and the hexadecimal value is shown with *. Please note, that the key must be typed in twice in order to save it.

Fig. 78: Create Mifare security key



3.7.6 Properties

Ticket properties are allocations of one or more keywords coming from the interface and the CDF definition; they represent the cen-tral element for access configuration. These properties provide the connection between ticket data records and the handshake™ configuration.

Ticket properties and their respective values may be created manually or automatically by the importer. The availability of indi-vidual ticket properties depends on the specified ticket system. When selecting the CDF for the ticket system, the corresponding keywords are generated automatically, the keywords of the Inter-face must be set up manually.

The ticket properties set up this way may be used for access con-figuration purposes, for statistics (handshake™ Reporter), or for both.

In case more than one client is working with the handshake™ system the ticket properties can be set Global and can be used for the configuration of the other clients.

There are four types of ticket properties:

individual ticket properties

grouped ticket properties with one allocated property. Indi-vidual properties can be allocated either by way of the group it-self, or by means of the allocated ticket property.

grouped ticket properties with more than one allocated property. Individual properties can only be allocated by way of the group itself.

ticket properties with control functionality

Fig. 79: Ticket properties




global property (can be used within the configuration of the other client)

When setting up a new ticket property you will be prompted to se-lect its type.

3.7.6.1 Individual ticket property

An individual ticket property implies a “1:1” mapping of ticket sys-tem keywords to the handshake™-specific ticket property.

Fig. 80: New ticket property

Fig. 81: Individual ticket property



You can specify any name for the property in the Ticket Prop-erty (30 characters) input box.

If Can be used for access configuration is activated, the ticket property can be used for creating permissions, verifications and system control tasks.

If the Can be used in reports options is checked, the ticket property will be available as an evaluation criterion in hand-shake™ Reporter.

Selecting Multiple property assignment means, that the ticket property can get multiple properties assigned through the inter-face e.g. ticket number valid for Event 2, Event 3, Event 7 etc.

When selecting Define identifications as global by default each time a new property is added it will be defined as a global property automatically. The global property can be used within the configuration of another client. The other client can use the property for his access configuration but cannot change or delete the property.

The flag Automatic event generation can only be activated after at least one ticket property is set up. If this flag is activated, each time a new property is added, the frame for setting up the event is opened automatically (see 3.8.2 Events).

Keyword on Ticket specifies the information needed to uniquely identify the ticket. The keywords available for this purpose depend on the CDF file (see 3.7.3.3 Keywords).

The Interface Keyword parameter describes the ticket informa-tion received from the ticket system via the interface. To be able to import ticket properties from the ticket system, the keyword must be allocated to a ticket property (see 3.7.2.6 Keywords).




3.7.6.2 Grouped ticket property

This function allows you to consolidate several individual ticket properties into a group.

The available individual ticket properties are organised into a sin-gle group. Through this grouping it is possible to create logical groups for the statistics.

The assignment of single ticket properties into grouped ones can be done within the group but also at the single ticket property (see 3.7.7.1 Activate ticket properties).

Fig. 82: Grouped ticket property



3.7.6.3 Ticket properties with control functionality

handshake™ can also receive and execute certain control func-tions from external ticket systems. The corresponding parameters can be relayed to handshake™ by way of an interface.

The following control functions are supported:

Additional releases (keyword ADDRELEASES) – is used within the actions (see 3.8.5 Actions).

Validity (keyword VALIDITY) – is used at the checks (see 3.8.4.5 Validity check).

Reader display text (keyword DISPLAYMESSAGE) – is used within the actions (see 3.8.5 Actions).

Time ticket Period (keyword TIMETICKETPERIOD) – is checked automatically when permission type Time-based ticket is used (see 3.8.3.5 Time-Based Ticket).

Points (keyword POINTS) – is used when permission type Point value or Groupticket is used (see 3.8.3.6 Groupticket).

Days (keyword DAYS) – is used when permission type Day ticket is used (see 3.8.3.2 Day Ticket).

Operator Message (keyword OPERATORMESSAGE) – is used within the actions (see 3.8.5 Actions).

Not assigned ticket property – when a keyword coming from the interface is assigned, the single properties must not be ac-tivated in order to be useable. (see 3.7.7.1 Activate ticket pro-perties).

Parking type (keyword ParkingType) describes the parking permission that is sent to the Parking.Logic Version 1.0.

Fig. 83: Ticket property with con-trol functionality




Parking Validity (keyword ParkingValidity) defines the time pe-riod fort he parking permission.

3.7.7 Imports

Depending on the configuration of the ticket system interfaces, data files are transferred to a directory on the handshake™ Server, from where it will be imported as scheduled (see 3.7.2.2 Interfaces).

The handshake™ Importer performs an automated import of ticket properties from the ticket system. The whitelist and black-list, which are also imported at regular intervals, are processed by handshake™ automatically and directly without the need for further user interaction.

When new properties are imported or recognized at the check-point (CheckEngine) this will be indicated in handshake™ Ex-plorer by a message to that effect.

Clicking on the boxed import message line will bring up an overview of current and existing data imports.

Fig. 84: Import information



Depending on the capability of the Ticketing partner, following in-formation can be imported through the interface

Whitelist – represents the list of sold tickets, validity informa-tion, control function (e.g. display text)

Blacklist – is the list of all blocked, cancelled, renewed etc. tickets and display texts

ticket properties – are the set up events, sector information, person categories etc. coming from the ticket system

Note: The properties being imported must exist for the ticket property import to be successful.

The import overview shows the new imports (ticket properties), all accepted imports (activated ticket properties and whitelist entries) and imports from the CheckEngine (checked tickets at the checkpoints with new ticket properties).

The Accepted Imports list shows all previous successful im-ports. The imported data records will not be displayed in detail. If importing was successful, the Error message column remains empty.

New imports and Data generated by the CheckEngine must be activated. Clicking on an Import date will bring up the corre-sponding information details.

Fig. 85: Import overview




When the imported data is allocated to defined ticket properties, they can be assigned by the way of activating them. The ticket properties with the new values are listed.

Click on any Name to bring up the new and existing property val-ues.

The import status is indicated by the following symbols:

The ticket property has been imported but has not been activated yet

The Check Engine has identified and imported the new ticket property directly at the checkpoint; however, the property has not been activated yet.

Ticket property has been imported via import process, but has not been activated yet; data import has already been committed or deleted.

The ticket property is activated

Newly imported ticket properties must be activated to allow the tickets with the new properties to be used at checkpoints.

To do so, click on the Edit symbol (I).

Fig. 86: Import details

Fig. 87: Imported identifier



3.7.7.1 Activate ticket properties

Single-click the newly imported ticket property to edit its name. Double-click the newly imported ticket property to activate it.

In case the ticket property is grouped (see 3.7.6.2 Grouped ticket property), the activated property can be allocated to the appropri-ate group in a single step.

Fig. 88: Edit ticket property

Fig. 89: Group ticket properties




When allocated to a group, the ticket properties automatically in-herit the properties of that group (e.g., when using the Sector group for entry authorisation).

In case there are ticket properties that are not assigned to exist-ing groups, a reminder message to that effect will be displayed as you close the window. If a ticket property is not assigned to any group, the reports will show a dash (“–”) instead of a property name.

3.7.8 Exports

The handshake™ Exporter is an own service looking for defined exports set up within the handshake™ Explorer. Depending on the defined action (e.g. transactions on checkpoint) a XML file is generated and exported to a defined destination. The hand-shake™ Exporter is installed using the handshake™ Server setup. With the help of the handshake™ Exporter transaction data is exported from the handshake™ database.

The file content consists of a header element and the transaction detail event venue, area, gate and checkpoint.

To create a new export set of to change an already existing one, click on edit.

Fig. 90: Not grouped ticket prop-erties

Fig. 91: Exporter



The standard export Channel type has to be selected, additional export channels can be added via an external setup.

The Name for the new Export can be freely defined. To switch off the export temporarily you can Disable the existing one. When selecting Ignore errors the export is not interrupted through to occurring errors.

The Directory defines the directory where the exporter places the file. The File name is the name for the exported file and is ex-tended automatically by the date, time and an ongoing number. The File size (MB) defines the maximum file size for the ex-ported files, whereas the Number of files is the maximum amount of files within the directory.

When activating Delete file if needed the old files will be over-written as soon as the maximum number of files within the direc-tory is reached.

The Ticketing System and the Interface for which the data should be exported have to be selected. The Version for the im-porter protocol is selected, standard selection is HSHIF25.

Fig. 92: New export




The Inquiry Parameters defines which data is exported:

Suppress raw data – the data element RawData including detailed information about the data stored on the original ticket is not exported

Suppress checkpoint information – the name of the check-point is not exported.

Suppress gate information – the name of the accessed gate is not exported.

Suppress area information – the name of the accessed area is not exported.

Suppress venue information – the name of the accessed venue is not exported.

Suppress TSProperty information – the ticket data imported from the ticket system is not exported.

Suppress detailed permission information – the detailed permission information of the used ticket is not exported.

Use new XML layout – if the new XML option is activated, all permissions of the used tickets are exported.

include erroneous transactions – all ticket transactions with error codes are exported.

include user defined counters – used defined counters are exported.

include transactions of other ticketing systems – all trans-actions from other ticket systems are exported.

include return codes of extended checks – the result codes of the extended checks are exported.

include logical date the transactions belongs to – the time detail of the ticket transaction is exported.

include inquiry timestamp – date and time of the export telegram are exported.

3.7.9 Extended checks

When using checks as condition or restriction additionally one or more extended checks can be configured. The result of the stan-dard check will be overruled.

Whenever a ticket property that triggers an extended check is read at an access point, the system uses the Extended Check.Interface to query that external system in order to deter-mine whether the ticket is valid. The ticket will be accepted only if this additional verification returns a positive result. If the result of the additional verification is negative, the checking procedure will be terminated and the ticket will be declined. If required, a waiting period can be defined for each additional verification to allow the user with the Handheld Terminal Application Soft Pinpad or Moni-tor to intervene.



The open, programmable Extended Check.Interface allows for the verification of additional access permission. This way, an ad-ditional verification can be integrated without the need to embed it into the product itself. The Extended Check.Interface SDK gives all the benefits of a fully programmable interface; the package comes complete with an interactive help system and sample code.

An example for existing plugins is the 550 Print@Home plugin so bar-coded tickets generated on Fair System 550 can be used on the Handshake.Logic access system or the bioscan plugin.

3.7.9.1 Two step validation

The two step validation is integrated in the handshake™ system automatically and is available after activating the extended checks (see 3.7.1 System settings).

When a ticket is read and verified at a checkpoint and that ticket matches a condition or restriction with two step validation, the ticket will not be declined straight away. This allows ticket inspec-tion staff to override the negative verification result via their Soft Pinpad or Monitor on the Handheld Terminal within a definable time. By confirming or overriding, the ticket inspection staff can decide whether to grant or deny access to the person in question. If the decision is not overridden or confirmed by staff within the specified time, the ticket will be declined.

A sample application of this functionality is double-use (anti pass back) restriction. If card holders need to leave the premises tem-porarily (for example, to get something from the car) staff will give them a stamp on their hand (to indicate that they are permitted to re-enter). When the card holder returns to be re-admitted, the card will normally be declined due to the double-use restriction. However, if two step validation is activated, the ticket will not be declined right away; instead, a member of staff can override the restriction to grant the person entry via Soft Pinpad.




To set up the two step validation, click the new symbol.

The Name for the new extended check can be freely defined.

The Sequence defines the priority of the extended check in case more than one extended check is in use.

When a ticket is read and verified at a checkpoint and that ticket matches a condition or restriction with two step validation the dis-play text and the operator message are shown. The checkpoint waits for "access granted" or "access denied" action sent from the Handheld Terminal Soft Pinpad or Monitor application (exe-cuted by staff).

If no action is sent during the Operator timeout, the standard ac-tion "access denied" is executed and the ticket is declined.

Fig. 93: Extended check



The two step validation is added to a check (see 3.8.4.3 Restrictions or 3.8.4.6 Conditions).

3.7.9.2 Plugin for Print@Home tickets from Fair system 550

Print@Home Tickets sold through the web shop for the fair sys-tem 550 can be scanned at the checkpoint ASx70i CF with op-tional print@home scanner.

Note: only valid system 550 barcode tickets in combination with checkpoint ASx70i CF with optional print@home scanner can be used. Handheld Terminals are not supported!

The ticket properties of the system 550 tickets are set up in handshake™ and will get entry permission. Additionally to the permit a condition has to be set up that uses the extended 550 check (see 3.8.4.6 Conditions). The final decision for granting ac-cess is requested directly from the fair system 550. The result must be a positive answer in order to open the turnstile. The re-ports showing the ticket usages are done at the fair system 550.

Fig. 94: Restriction and extended check (two step validation)




3.7.10 Result codes

The result codes comprise the list of all possible events that can occur within the handshake™ system and can be adapted as re-quired.

Each event is assigned to a specific Type. The possible code types can be Warning, Hint, internal system error or error.

Classifying the code as Irregularity Yes will include the code within the irregularity reports (see chapter 4 Reporter, 4.6 Irregu-larities). If it is set to Irregularity No, the code will not appear in the reports.

Depending on the installation, the listed result codes can be ex-ported to a file or to the IBM-Message Queue. The export service reads the entries of the message queue and leads them to further external processing.

Fig. 95: Result codes



3.7.10.1 New result code

To realize user defined error actions, new user defined result co-des are setup. For all situations where tickets are declined (de-nial, condition failed and restrictions) user defined result codes can be assigned and will show specific display texts (see 3.8.4 Checks).

The Name and Description will help to identify the result code. The Display message is used as standard display text and can be overwritten by setting up an error action (see 3.8.7 Error ac-tions).

As selectable Type for the result code Hint, Warning, Error or In-ternal system error are available. To show the occurred result codes within the irregularity reports, Irregularity Yes has to be selected. The standard value for Manual release is set to No, only when the result code should be counted as manual release the value has to be set to Yes. To send the result code to the ex-porter automatically (see 3.7.8 Exports) in case it occurs, the Ex-porting has to be set to Yes. Standard value is set to No.

Important: in order to use the result codes for checks and error actions, the Type must be set to Error.

Within the error actions the result codes will be assigned and dis-play texts, signal lights etc. are set up (see 3.8.7 Error actions). In case the error action occurs e.g. a denial applies, the corre-sponding display text is shown and the action is listed within the irregularities, depending on the result codes setting.

Fig. 96: New result code


Access configuration 3.8


3.8 Access configuration

A ticket will be accepted at a checkpoint if a permission type and at least a positive verification exists for the properties of this ticket.

In the handshake™ system, the following designations are used:


Designation Explanation Permission types Determines the value behaviour of tickets. Checks Check in the form of a permit, condition, restriction, denial, validity check,

or control function. Permit A permit specifies when and where a specific ‘ticket’ (Ticket property) may

be used to gain access to the premises; the ticket will be verified at the checkpoint. The permit is the base for further check.

Condition Introduces extended permissions for a ticket in addition to admission. Restriction Imposes a constraint on the possible use of a data carrier or the permis-

sion to access certain areas, events or the entire premises (e.g., the maximum number of allowed re-entries).

Denial An explicit exclusion of tickets. Validity Check Builds on whitelist procedures and performs an additional date check in

addition to admission. Control Function The control function is used to modify the behaviour of reader or turnstile

with the use of a ticket directly at the checkpoint Actions Actions specify the behaviour of checkpoints with respect to assigned

Ticket properties in case of a positive verification result. Point Deductions The number of points to reduce from the ticket at the entrance. Error Actions All possible disturbances at the checkpoints are allocated to error codes.

To show customer friendly display messages at the checkpoints, all pos-sible errors (e.g. area entries exceeded) can get self defined error mes-sages, light and tone signals.

Extended Emergency mode The extended emergency mode needs to be activated, in order to check additional properties coded in the barcode or chip during an emergency mode situation.

Extended check When using checks as condition or restriction additionally one or more extended checks can be configured. The result of the standard check will be overruled.

Two Stepp validation When a ticket is read and verified at a checkpoint and that ticket matches a condition or restriction with two step validation, the ticket will not be de-clined straight away. This allows ticket inspection staff to override the negative verification result via their Soft Pinpad or Monitor on the Hand-held Terminal within a definable time.

3 Handshake.Logic – Explorer 3.8 Access configuration


3.8.1 Event overview

When more than one client is working on the system, the event venue configuration is activated by the layout. Events can be u-sed to activate layouts.

Within the event overview all setup events of all clients are shown.

The event activating the layout currently in use is shown as Ac-tive.

3.8.2 Events

Events are used

to assign the ticket transactions at the checkpoints to the event, and therefore be able to create event related reports

to activate layouts and to create checks for the areas used within the event (layout).

When setting up the event, the Start and End date as well as the from until time is defined. Within this time period, the ticket transactions are assigned to the event and the checks set up for the event are used.

The event can also be within single areas of the layout, not marked areas are inactive during the set time period.

Fig. 97: Event overview




3.8.3 Permission types

Permission types determine the basic value behaviour of tickets within a specific period. Each verified ticket is assigned the basic value behaviour based on the permission types defined in this dialogue.

The basic value can be overruled by the ticket system using the interface to do so. handshake™ distinguishes between season tickets, Day Tickets, Non-Consecutive Day Tickets, Point Tickets, time-based tickets and Group tickets.

The validity period of the permission is valid during a time "from" "to" for every day starting with the start date (see 3.6.2 Regular periods).

Fig. 98: Event



In case a ticket cannot be assigned to another authorisation when read at the checkpoint, it will be assigned to the standard authorisation instead (this is indicated by bold characters). Note that only one standard authorisation can be created.

Note: The standard permission may not be used for a permit.

3.8.3.1 Season Ticket

Usually unlimited validity Validity termination is defined by the period the keyword VALIDITY received per Whitelist, defines the va-

lidity when using the validity check (see 3.8.4.5 Validity check)

3.8.3.2 Day Ticket

Valid for 1 to 1,000 days Multiple-day tickets must be up used on consecutive days Validity termination is set at first use the number of days can be overwritten for each single ticket

using the keyword DAYS received per Whitelist the keyword VALIDITY received per Whitelist, defines the va-


3.8.3.3 Day Ticket (non consecutive days)

Valid for 1 to 1,000 days

Fig. 99: Permission type




Multiple-day tickets can be up used on non consecutive days within a specific period of time

Validity termination is set at first use the number of days can be overwritten for each single ticket

using the keyword DAYS received per Whitelist the keyword VALIDITY received per Whitelist, defines the va-


3.8.3.4 Point value

1 to 999,999 points The number of points to be debited for one admission is de-

fined by the point reduction parameter The expiration of the validity is set when the ticket is used for

the first time The number of points can be overwritten for each single ticket

using the keyword POINTS received per Whitelist. the keyword VALIDITY received per Whitelist, defines the va-

lidity when using the validity check (see 3.8.4.5 Validity check) The necessary point deduction can be set up automatically.

3.8.3.5 Time-Based Ticket

Validity of 1 to 999,999 minutes If the ticket is used after its time credits are used up, the

checkpoint will automatically refuse admission. The default time credit can be overwritten for each single

ticket using the keyword TIMETICKETPERIOD received per Whitelist.

The ticket can be programmed with a specific check-out time limit.

Ticket details such as the remaining time credit, as well as used-up time and the total time credit can be shown on the display of the checkpoint.

The ticket can be optionally configured to be valid from the time of issue, a specific time, or when used for the first time.

If the ticket is assigned to a specific area, the timer stops as soon as the ticket holder leaves this area.

Exact check-in/check-out verification is automatically acti-vated.

the keyword VALIDITY received per Whitelist, defines the va-lidity when using the validity check (see 3.8.4.5 Validity check)

3.8.3.6 Groupticket

The group ticket is used for the access of a bigger amount of people with one ticket.

The properties of a Groupticket include: the number of passages can be 1 to 1,000.



The default group size can be overwritten for each single ti-cket using the keyword POINTS received per Whitelist.

The automatic end of group (counting) can be set in seconds. If nobody passes within this time period, meaning that the bar-rier does not send a signal, the group is considered as every-body passed.

The passages needn't to be one after another, that means that if the passage of the group is interrupted, it can continue after the group ticket is checked again so the rest of the group is allowed to pass.

Ticket details such as the remaining, as well as used-up time and the total number of persons on the group ticket can be shown on the display of the checkpoint.

The necessary point deduction can be set up automatically.

3.8.3.7 Set up a permission

To edit a handshake™ permission or set up a new one, proceed as follows:

Enter a Name (30 characters) and Description for the permis-sion and select a Permission Type to define the value behaviour of the ticket (e.g. Day Tickets, Non consecutive day…).

If you selected Day Ticket as the basic permission, you can acti-vate the field valid unlimited. If so, there will not be an expiry date to the Day Ticket.

Fig. 100: Permission type




Select a valid during from the list of the ones previously defined, or enter a New period.

In case of a day ticket, you will need to enter the number of valid days, in case of point tickets the number of points, using time-based tickets requires the number of minutes and a toler-ance margin. The size for group tickets is entered, when group ticket is selected. To ensure correct time calculation for time-based cards, it is necessary to specify the region (locale) when creating a time-based card.

By activating Default you decide for the system to use this stan-dard value behaviour for all tickets that are known to the system but not configured.

Right-click in the lower part of the dialogue window to bring up the context menu. Select Add new group to set up a new group, or Edit Group to modify the existing group.

The displayed groups represent the defined ticket properties (see 3.7.6 Properties). Select the Ticket properties that should deter-mine the behaviour of the ticket.

Fig. 101: Add new group



3.8.4 Checks

handshake™ provides the following verification methods:

Permit Condition Restriction Denial Validity Check Control Functions

The Permit is the base for using all other types of check. Every ticket being verified must have at least one applicable permit (otherwise it will be rejected).

Permits, Denials and Conditions can be checked also in ex-tended emergency mode at the checkpoint.

3.8.4.1 Permit

The Permit setting defines which ticket property should be veri-fied at the gates within a specific period.

Note: For accessing the venue, the tickets properties must meet at least one permit!

When the ticket used at the checkpoint does not meet the defined permit an appropriate “ACCESS NOT ALLOWED" message is displayed (error action Ticket check: Access denied 103).

Fig. 102: Checks




When setting up a new check ( ), you must select the type of check (i.e., permit, denial etc.). In case you have already edited an existing verification record (via I), you will no longer be able to change the method (Type of Check).

Enter an appropriate Name (30 characters) for the check that al-lows it to be easily identified.

Select an existing Period or enter a new one in which the permit will be valid. Here, the period is defined such that from Start Date to End Date Validity applies on selected week days between the two points in time specified (see 3.6.2 Regular periods).

Checks can be set up for Both directions (standard setting). To disable a check temporarily the check can be Not in use, it will not be considered when tickets are checked. Permits, conditions and actions can be set to work either in Entry or Exit direction.

Permit, denial and condition can be used for the extended emer-gency mode, the check can be done in Online, Offline or Online and offline mode, the selection when to use has to be made (see 3.8.4.7 Extended emergency mode).

Fig. 103: Check setup



Therefore the decision to use the check in online, offline or both has to be made (see 3.8.4.7 Extended emergency mode) when setting up a check.

The list on the Assigned Locations tab contains all configured locations of the event venue. The smallest location unit to which admission verification can be applied is an access gate (group of checkpoints). When selecting an event, the defined verification scheme will apply to the allocated layout within the defined event period.

On the Assigned Identifiers tab you can select the ticket proper-ties that should be included in the verification procedure.

Right-click in the lower section of the window will bring up a con-text menu with options for setting up a new group (Add new group), edit (Edit group) or deleting (Delete group) existing groups.

The list of assigned identifiers shows the available ticket proper-ties (see 3.7.6 Properties). The list contains only those properties for which values have been defined.

Click on the + sign in front of a ticket property name to view its defined values.

Fig. 104: Property values




Select the ticket properties you wish to be included in the ticket verification procedure. Click the Save button to store the new configuration. Finally, click the OK button in the setup dialogue to accept the configuration of the permission.

3.8.4.2 Denial

The denial specifies a ticket property that is checked for at checkpoints during a specific time period and does not entitle the ticket holder to admission. If this ticket property is detected on a ticket during verification, the turnstile at the checkpoint is not re-leased.

Note: The denial is an explicit exclusion. The denial is set up additionally to the permit.





When the properties of the ticket used at the checkpoint meets the defined denial, an appropriate “ACCESS DENIED” message is displayed (error action Ticket check: Denial applies 104). The standard result code can be replaced using user defined result codes (see 3.7.10 Result codes).

Fig. 105: Denial: display mes-sage




The list on the Assigned Locations tab contains all configured locations of the event venue. The smallest location unit to which admission verification can be applied is an access gate (group of checkpoints). When selecting an event, the defined verification scheme will apply to the allocated layout within the defined event period.



The list of assigned identifiers shows the available ticket proper-ties (see 3.7.6 Properties). The list contains only those properties for which values have been defined. Click on the + sign in front of a ticket property name to view its defined values.

Select the ticket properties you wish to be included in the ticket verification procedure. Click the Save button to store the new configuration. Finally, click the OK button in the setup dialogue to accept the configuration of the permission.

3.8.4.3 Restrictions

You can define various restrictions to set re-entry, anti pass back and waiting period limits for events, areas and venues.

Upon selection Type of check Restriction, the window in which restriction types can be selected is opens automatically. To de-fine a restriction, click on New Restriction.




Checking for can apply to the permission or to the data carrier. A keycard can hold various different permissions.

Restriction Type specifies one of the following values:

Number of Re-entries Number of re-entries per day Waiting period for re-Entry Anti-pass back time entry-direction Waiting period for re-Exit Anti-pass back time exit-direction

Checking against specifies against which entered/left area the permission should be checked. The following options are avail-able, depending on whether the restriction applies to entry or exit:

visited / left events visited / left areas visited / left venues All visited / left events All visited / left areas All visited / left venues

Depending on the restriction type, enter the Quantity of re-entries, or the double-usage or Time period in seconds, minutes, hours or days.

You can use several restriction types within one restriction. To select the next restriction type, click "New Restriction" again. Af-ter setting up all necessary restriction, close the window by click-ing OK.

Fig. 106: Restriction



Enter a Name (30 characters) for the restriction so you can clearly recognize it in the system.

Select an existing Period or enter a new one in which the restric-tion will be checked. Here, the period is defined such that from Start Date to End Date Validity is given on selected week days between the two points in time specified (see 3.6.2 Regular peri-ods).

Restrictions can be set up for Both directions (standard setting). To disable a check temporarily the check can be Not in use, it will not be considered when tickets are checked.

If a defined restriction applies, an appropriate error message will be displayed at the checkpoint, depending on the type of restric-tion (e.g. Venue: double use waiting period to enter is not yet up (112) DOUBLE USAGE NOT ALLOWED). The standard result code can be replaced using user defined result codes (see 3.7.10 Result codes).

In case the two step validation is activated (see 3.7.1 System set-tings) and defined (see 3.7.9.1 Two step validation), it can be as-signed to the restriction. The ticket with the corresponding properties is not rejected immediately. The control person can grant or deny access via the Soft Pinpad or the Monitor applica-tion on the Handheld Terminal within a definable time.

The list on the Assigned Locations tab contains all configured locations of the event venue. The smallest location unit to which restrictions can be applied is an area (gates leading into the area). When selecting an event, the defined verification scheme will apply to the allocated layout within the defined event period.




Select the ticket properties you wish to be included in the ticket verification procedure. Click the Save button to store the new




configuration. Finally, click the OK button in the setup dialogue to accept the configuration of the restriction.

3.8.4.4 Control functions

The control function is used to modify the behaviour of reader or turnstile with the use of a ticket directly at the checkpoint. When selecting Type of check Control function, the following Control functions can be selected from the options:

Change mode to permanent open – Reader will activate per-manent open mode when ticket is used (only ADA turnstile)

Change to Block Mode– Reader will activate blocked mode when ticket is used

Change to Free Passage Mode – Reader will activate free passage mode when ticket is used

Change to Out of Service Mode– Reader will activate Out of Service mode when ticket is used

Change to Ticket Check Mode– Reader will activate Ticket Check mode when ticket is used

direction switch inverse – the turnstile is switched to the oppo-site direction (entrance becomes exit)

direction switch regular – the turnstile is switched back to the configured (standard) direction

direction switch toggle – every time the ticket is used, the turnstile is switched to the opposite direction (entrance be-comes exit, exit becomes entrance)

Reset counters – Using this control card will cause the counter to be reset to 0.

Single manual turnstile release – Reader will release the turn-stile for a single passage

The selected control function can be assigned to a result code. Whenever a control card is used, this will be shown within the ir-regularities report. Control functions can be set up in the same way as permissions.

If the specified ticket property is detected on a ticket upon verifi-cation at a checkpoint, the designated control function (System: control card accepted (051) is executed and CONTROL CARD IS ACCEPTED is displayed. The standard result code can be re-placed using user defined result codes (see 3.7.10 Result codes).



3.8.4.5 Validity check

A validity check provides an additional way of checking a ticket and requires a ticket system with whitelist support.

Tickets with the additional VALIDITY property that will be checked with respect to the validity date in the whitelist sent through the interface by the ticket system. When configuring a validity check for a ticket property, a whitelist entry must exist for the validity of the ticket (keyword VALIDITY).

When the time period of the validity is exceeded, the error action Ticket check: validity check failed (109) is released and TICKET NOT VALID NOW is shown in the display of the checkpoint. The standard result code can be replaced using user defined result codes (see 3.7.10 Result codes).

The procedure for setting up a validity check is the same as for setting up a permit.

3.8.4.6 Conditions

Conditions represent additional permissions. When the ticket is verified, both the permit and the condition are checked. To entitle its holder to pass through a checkpoint, the ticket must meet at least one defined permits and all conditions.




Fig. 107: Display message con-trol function





When the ticket used at the checkpoint does not meet the defined condition an appropriate “ACCESS NOT ALLOWED" message is displayed (Ticket check: condition failed 130). The standard re-sult code can be replaced using user defined result codes (see 3.7.10 Result codes).


In case the two step validation is activated (see 3.7.1 System set-tings) and defined (see 3.7.9.1 Two step validation), it can be as-signed to the restriction. The ticket with the corresponding properties is not rejected immediately. The control person can grant or deny access via the Soft Pinpad or the Monitor applica-tion on the Handheld Terminal within a definable time.

The list on the Assigned Locations tab contains all configured locations of the event venue. The smallest location unit to which restrictions can be applied is an area (gates leading into the area). When selecting an event, the defined verification scheme will apply to the allocated layout within the defined event period.




Select the ticket properties you wish to be included in the ticket verification procedure. Click the Save button to store the new configuration. Finally, click the OK button in the setup dialogue to accept the configuration of the restriction.



3.8.4.7 Extended emergency mode

When setting up the ticketing system, the definition of the CDF decides if the extended emergency mode should be used (see 3.7.3 Code definitions). Through this activation of the extended emergency mode it is possible to check ticket properties at the checkpoints when they work in emergency mode.

The main requirement for the extended emergency mode is the availability of ticket properties directly coded on the ticket.

Ticket properties only available through the whitelist can not be used for checks in extended emergency (offline) mode.

Note: Only checks of type permit, condition and denial can be used for the extended emergency (offline) mode.

The listed checks will show an additional symbol for the usage during extended emergency (offline) mode.

Online – the check works only during online mode.

Online and Offline – the check works during online and off-line mode.

Offline – the check works only during offline mode.

When synchronizing the system, the necessary data are downloaded to the checkpoints. When a checkpoint is in an off-line situation, and the extended emergency mode is activated, the basic input parameters of the ticketing system (see 3.7.3 Code definitions) are checked as before but also depending on the configuration the checks used for offline mode.

If the extended emergency mode is not active, only the basic in-put parameters of the ticketing system will be verified.

3.8.4.8 Ticket check procedure

Tickets scanned at the checkpoints are processed in the way de-scribed bellow:

CDF-check – checks the system parameters of the CDF and the correct coding of the ticket – if check fails error code 33

Whitelist-check – if whitelist is set to Yes, the unique ticket ID must be part of the current whitelist – if check fails error code 106




Blacklist-check – if blacklist is used and the scanned ticket ID is found in the blacklist – error code 128 datacarrier blocked or 129 permission blocked

Permit check – a permit must exists, that meets the date and the checkpoint where the ticket is scanned at – check fails er-ror code 103

Denial check – if an existing denial applies error code 104 Restriction check – if tickets is used based on the restriction

used for the event venue, area or event time period an error code depending on the configured restriction is shown e.g. Area: today´s maximum of entries exceeded (126)

Validity check – if the validity check is activated, the from to date contained in the whitelist is checked against the current time and date – if check fails error code 109

Condition check - if an existing condition applies to the ticket property coded on the ticket error code 130

3.8.5 Actions

Actions will only be triggered if ticket verification is positive. In any other case (i.e., error situations) you can set up separate er-ror actions (see 3.8.7 Error actions).

Actions can be used to activate certain sound and light signals, or trigger additional turnstile releases.

Depending on the installed reader type, the reader display can display e.g. for the ASx70i CF up to 2 lines at 16 characters each. You may also define an alternating display text; in that case the two screen messages will be displayed alternately at 2-second intervals; this can be used to realise multi-lingual wel-come messages.

When attaching an additional display to the checkpoint, the con-trol person can get an extra operator display message.



Using defined placeholders can be used to show authorisation values (e.g. the current value), counter values (e.g. current counter value) and Ticket Properties (e.g. 1 day Adult) in the readers display for each single ticket.

If system counters and user counters are available, these may be assigned to specific countable transactions (blocking and neutral transactions).

Note: Counter-related actions can only be set up (i.e., de-fined) when creating system or user counters. The “Actions” function will only allow you to edit or delete them.

To edit actions or set up new ones, proceed as follows:

Fig. 108: Action

Fig. 109: Action




Selecting Displaytext Default will cause the standard text to be displayed in case of a positive ticket verification result.

Selecting Display text as userdefined will bring up a dialogue allowing you to enter two lines of text at a maximum of 16 charac-ters each. Select Alternate text to enter a second text message having two lines each 16 characters.

The DISPLAYMESSAGE and OPERATORMESSAGE value can be transmitted from the ticket system to handshake™ via the XML interface. To use this property and have the message dis-played if it exists, select the option defined by the ticketsystem.

Same settings can be made for the Operator message, if opera-tor displays are installed at the checkpoints.

The displaytext of the checkpoint displays are shown in the fol-lowing order:

on entering (Entry direction) the venue: Displaytext from Whitelist – defined by the ticketsystem Displaytext taken from action – userdefined Displaytext default – Welcome

on exiting (Exit direction) from the venue: Displaytext taken from action – userdefined Displaytext from Whitelist – defined by the ticketsystem Displaytext default – Welcome

To set up a variable display text click … . Please note that the text is cut off in the checkpoints display in case of exceeding the maximum number of 16 characters.

Fig. 110: Edit display text



Permission value current value

e.g., %CV% points displays as “100 Points” (example) needed value

e.g., %NV% more points required = “50 more Points required” total

e.g., %TV% Points Ticket = “100 Points Ticket” used value

e.g., %UV% points used = “50 points used”

Counter values current value

e.g., %CO% persons already on premises = “123 persons al-ready on premises”

upper limit e.g. maximum %UL% person allowed to enter = maximum 1200 person allowed to enter

lower limit e.g. minimum %LL% reached = minimum 10 reached

remaining to upper limit %RV% persons still allowed = 22 persons still allowed

Ticket property shows all available ticket properties (see 3.7.6.1 Individual

ticket property) available for the access configuration.

Light signal can be selected from the following options

Default no light signal green light signal flashing green light signal red light signal flashing red light signal red and green flashing synchronously red and green flashing alternately yellow light signal flashing yellow light signal

Acoustic signals can be selected from the following options:

Default No sound Single beep Double beep Three beeps

Number of escorts userdefined can be used for small groups of people passing with one ticket, e.g. 1 ticket holder and 3 escorts.




The maximum number of possible escorts is 3. The passages have to be one after another, without use of another ticket in be-tween. Otherwise the not used passages will be no longer avail-able. When selecting defined by the ticketsystem, the value of the ticket property ADDRELEASES existing in the whitelist is used. To realise groups of more than 4 people, the group ticket functionality is used (see 3.8.3.6 Groupticket).

The direction for the action can be set to Entry , Exit , Both directions and not in use.

3.8.6 Point deduction

The number of points to be debited for one admission is defined by the point reduction parameter. The point deduction is used also for group tickets. The group size is sent through the interface XML-File coming from the Ticket System using the keyword POINTS.

The point deduction is set up additional to the permit. The amount of points reduced from the ticket passing the used en-trances within the set time period is set up in this frame.

When using group tickets, 1 point for 1 entry is deducted, that means that one turnstile turn is counted for each person and re-duces the amount of the total group size.

To edit a point deduction or set up a new one, proceed as fol-lows:



Enter a Name (30 characters) for the point deduction so you can clearly recognize it in the system.

Select an existing Period or enter a new one in which the point deduction will be checked. Here, the period is defined such that from Start Date to End Date Validity is given on selected week days between the two points in time specified (see 3.6.2 Regular periods).

Put in the amount of Points Necessary for the number of entries using a point ticket at the selected gates.

The list of Assigned locations contains all configured locations of the event venue. The smallest location unit to which point de-duction can be applied is a gate.

When selecting an event, the defined point deduction scheme will apply to the allocated layout within the defined event period. This is because in handshake™ events are always associated with a particular time period and layout. The layout is activated auto-matically at the designated start time of the event. The event sta-tistics can be evaluated with handshake™ Reporter.

Fig. 111: Point deduction




3.8.7 Error actions

The display messages for system errors at checkpoints are cus-tom configurable. This allows you to have your own error mes-sage displayed instead of the default message.

Depending on the installed reader type, the reader display can display e.g. for the ASx70i CF up to 2 lines at 16 characters each. You can also define a second message to have the two texts displayed alternately at two-second intervals. This feature can be used, for example, to display error messages in two lan-guages. To find out about problem situations at the checkpoints light and acoustic signals can be used. When operator displays are installed at the checkpoints, additional information can be shown to the control personal standing at the entrance.

Using variable placeholders permission values (e.g. current value of the ticket), counter values (e.g. current counter value) and ticket properties (e.g. Adult 1 day) can be displayed. The dis-played list of the possible errors is taken from the result codes (see 3.7.10 Result codes). To show user defined error display texts, new result codes of type error can be set up (see 3.7.10.1 New result code).

Fig. 112: Error action



To edit actions or set up new ones, proceed as follows:

Selecting Displaytext Default will cause the standard text to be displayed in case of a negative ticket verification result (see Fehler! Verweisquelle konnte nicht gefunden werden.).

Selecting Display text as userdefined will bring up a dialogue allowing you to enter two lines of text at a maximum of 16 charac-ters each. Select alternating Text to enter a second text mes-sage having two lines each 16 characters.

The DISPLAYMESSAGE and OPERATORMESSAGE value can be transmitted from the ticket system to handshake™ via the XML interface. To use this property and have the message dis-played if it exists, select the option defined by the ticketsystem.

Same settings can be made for the Operator message, if opera-tor displays are installed at the checkpoints.

The displaytext of the checkpoint displays are shown in the fol-lowing order:

on entering (Entry direction) the venue: Displaytext from Whitelist – defined by the ticketsystem Displaytext taken from action – userdefined Displaytext default – Welcome

on exiting (Exit direction) from the venue: Displaytext taken from action – userdefined Displaytext from Whitelist – defined by the ticketsystem Displaytext default – Welcome

Fig. 113: Edit error action




To set up a variable display text click … . Please note that the text is cut off in the checkpoints display in case of exceeding the maximum number of 16 characters.

Permission value current value

e.g., %CV% points displays as “100 Points” (example) needed value

e.g., %NV% more points required = “50 more Points required” total

e.g., %TV% Points Ticket = “100 Points Ticket” used value

e.g., %UV% points used = “50 points used”

Counter value current value

e.g., %CO% persons already on premises = “123 persons al-ready on premises”

upper limit e.g. maximum %UL% person allowed to enter = maximum 1200 person allowed to enter

lower limit e.g. minimum %LL% reached = minimum 10 reached

remaining to upper limit %RV% persons still allowed = 22 persons still allowed

Ticket property shows all available ticket properties (see 3.7.6.1 Individual

ticket property) available for the access configuration.

Fig. 114: Edit display text



Light signals can be selected from the following options

Default no light signal green light signal flashing green light signal red light signal flashing red light signal red and green flashing synchronously red and green flashing alternately yellow light signal flashing yellow light signal

Acoustic signals can be selected from the following options:

Default No sound Single beep Double beep Three beeps

After setting all necessary details, select the possible error from the list and assign it using a double mouse click or by clicking symbol >. You can of course assign multiple error codes to one error action.

Note: user defined result codes of type error are shown at the bottom of the list of possible error codes.

The standard error messages shown at the checkpoints are re-placed by the ones set up via the error actions. The display of er-ror messages at the Access Manager user interface is not replaced by error actions.




Tab. 8: Standard error actions

Error Action Access Manager Display Text Checkpoint

Area: entries exceeded (115) ERR Area entries exceeded AREA ENTRIES EXCEEDED

The maximum number of re-admissions to the specified area has been exceeded.

Area: entry waiting period is not yet up (116)

ERR Area re-entry waiting period AREA RE-ENTRY WAITING PERIOD

The waiting period for re-admission to the area has not yet elapsed.

Area: double use waiting period to enter is not yet up (117)

ERR Area double usage in entry direction not allowed

AREA ENTRY DOUBLE-USAGE NOT ALLOWED

The waiting period for re-using the ticket to enter the specified area has not yet elapsed.

Area: exit waiting period is not yet up (118)

ERR Area re-exit waiting period AREA RE-EXIT WAITING PERIOD

The waiting period for re-admission to the specified area has not yet e-lapsed.

Area: double use waiting period to exit is not yet up (119)

ERR Area double usage in exit direction not allowed

AREA EXIT DOUBLEUSAGE NOT ALLOWED

The waiting period for re-using the ticket to exit the specified area has not yet elapsed.

Area: today's maximum of entries exceeded (126)

ERR Todays Area entries exceeded TODAYS AREA ENTRIES EXCEEDED

The maximum daily number of re-admissions to the specified area has been exceeded.

Counter: Admission limit ex-ceeded (150)

ERR Admission limit exceeded ADMISSION LIMIT EXCEEDED

A system or user counter reached the pre-set upper limit.

Event: today's maximum of entries exceeded (127)

ERR Todays Event entries exceeded TODAYS EVENT ENTRIES EXCEEDED

The maximum daily number of re-admissions to the event has been ex-ceeded.

Event: entries exceeded (120) ERR Event entries exceeded EVENT ENTRIES EXCEEDED

The absolute maximum number of re-admissions to the event has been exceeded.

Event: entry waiting period is not yet up (121)

ERR Event re-entry waiting period EVENT RE-ENTRY WAITING PERIOD

The waiting period for re-admission to the event has not yet elapsed.

Event: double use waiting period to enter is not yet up (122)

ERR Event double usage in entry direc-tion not allowed

EVENT ENTRY DOUBLE-USAGE NOT ALLOWED

The waiting period for re-using the ticket for re-admission to the event has not yet elapsed.





Event: exit waiting period is not yet up (123)

ERR Event re-exit waiting period EVENT RE-EXIT WAITING PERIOD

The waiting period for re-exiting the event has not yet elapsed.

Event: double use waiting period to exit is not yet up (124)

ERR Event double usage in exit direction not allowed

EVENT EXIT DOUBLEUSAGE NOT ALLOWED

The waiting period for re-using the ticket to exit the event has not yet elapsed.

Extended check failed (36) ERR Extended check failed ADDITIONAL CHECK FAILED

The extended check failed.

System: ticket not readable (031) ERR Ticket not readable TICKET NOT READABLE

The system was unable to read the data stored on the ticket.

System: ticket type unknown (033) ERR Ticket not known in system TICKETTYPE UNKNOWN The ticket has an unknown format (CDF input parameter) System: Ticket manipulated (037) ERR Ticket manipulated TICKET

NOT ALLOWED The scanned data medium seems to be manipulated.

System: ticket write error (038) ERR Ticket write error TICKET WRITE ERROR

A write error occurred during scanning a contactless data medium. The necessary information could not be written on the ticket.

System: recording failed (200) ERR Ticket Data saving failed TICKET NOT ALLOWED INTERNAL ERROR

The system was unable to store the data read from the ticket.

Ticket check: access denied (103) ERR Access not allowed ACCESS NOT ALLOWED

The access permission to check for does not exist on the ticket in ques-tion; the ticket holder is denied access.

Ticket check: Denial applies (104) ERR Access not allowed ACCESS NOT ALLOWED

The non-permission to be checked for applies to the ticket in question.

Ticket check: day ticket, long term ticket valueless (105)

ERR Ticket value expired TICKET VALUELESS

There are no more day credits available on the ticket for the permission in question.

Ticket check: no whitelist record (106)

ERR Ticket unknown TICKET UNKNOWN

The permission to be verified is not included in the whitelist (whitelist clearance is required as per CDF configuration)

Ticket check: permission type unknown (108)

ERR Permission type unknown PERMISSION TYPE UNKNOWN

There is no verification type defined for verifying the ticket in question.






Ticket check: validity check failed (109)

ERR Ticket not valid TICKET NOT VALID

Verification of the ticket’s validity yielded a negative result (the validity date is not included in the whitelist).

Ticket check: datacarrier blocked (128)

ERR Datamedium is blocked DATAMEDIUM BLOCKED

A blacklist entry exists for the data carrier in question. The data carrier has been blocked.

Ticket check: permission blocked (129)

ERR Permission is blocked PERMISSION BLOCKED

Indicates that a blacklist entry exists for the permission in question. The permission will be blocked.

Ticket check: condition failed (130)

ERR Access not allowed ACCESS NOT ALLOWED

The ticket in question does not meet the condition being checked for.

Ticket check: insufficient point credit – point deduction (131)

ERR Ticket has not enough points %D% POINTS REQUIRED

The required number of points could not be deducted due to an insuffi-cient point credit.

Ticket check: point ticket value-less (132)

ERR Point Ticket valueless NO POINTS LEFT

There are no more point credits available on the ticket for the permission in question.

Ticket check: time limit exceeded (135)

ERR time limit exceeded TIME LIMIT EXCEEDED

The time credit of the ticket has exceeded.

Ticket check: time-based ticket has already entered (138)

ERR time ticket already entered TIME TICKET ALREADY ENTERED

The ticket used at the entry gate has been already used for entry.

Ticket check: time-based ticket has already left (137)

ERR time ticket already left TIME TICKET ALREADY EXIT

The ticket used at the exit gate has been already used for exit.

Ticket check: time-based ticket has not entered yet (139)

ERR time ticket not entered yet TIME TICKET NOT ENTERED

The ticket used at the exit gate has been not used for entry.





Venue: today´s maximum of en-tries exceeded (125)

ERR Todays Venue entries exceeded TODAYS VENUE ENTRIES EXCEEDED

The maximum daily number of re-admissions to the specified venue has been exceeded.

Venue: entries exceeded (110) ERR Venue entries exceeded VENUE ENTRIES EXCEEDED

The absolute maximum number of re-admissions to the event venue has been exceeded.

Venue: entry waiting period is not yet up (111)

ERR Venue re-entry waiting period VENUE RE-ENTRY WAITING PERIOD

The waiting period for re-admission to the venue has not yet elapsed.

Venue: double use waiting period to entry is not yet up (112)

ERR Venue double usage in entry direc-tion not allowed

ENTRY DOUBLEUSAGE NOT ALLOWED

The waiting period for re-using the ticket to enter the venue has not yet elapsed.

Venue: exit waiting period is not yet up (113)

ERR Venue re-exit waiting period VENUE RE-EXIT WAITING PERIOD

The waiting period for re-exiting the specified venue has not yet elapsed.

Venue: double use waiting period to exit is not yet up (114)

ERR Venue double usage in exit direc-tion not allowed

EXIT DOUBLEUSAGE NOT ALLOWED

The waiting period for re-using the ticket to exit the venue has not yet elapsed.




3.8.8 Counter

With the help of system and user counters it is possible to set up a quota control system directly at the checkpoints. Every time a turnstile is opened and closed in entry direction, the counter is in-cremented by 1 resp. decremented by 1 in exit direction. If a limit has been defined, the system checks after each passage if that limit has been reached. If this is the case, the checkpoint stops accepting tickets, and the barrier locks.

Counting is in both directions (entry and exit) and covers the fol-lowing transactions:

All gate passages after positive ticket validation All additional gate passages and releases All passages taking place while the checkpoint is set to Free

Passage

Customised display messages, as well as visual and acoustic signals indicate various status values at the checkpoint, including the current counter reading, and the number of admissions pos-sible before the pre-set maximum is reached. The user counters can be edited and reset via SKIDATA Monitor.

3.8.9 System counter

These counters are created automatically when setting up venue sections, layouts, areas, access gates, checkpoints, and events. System counters cannot be deleted or restricted to specific ticket types. They always count all gate passage transactions.

Important: When setting up venue or areas and activating the upper limit, the checkpoints will be blocked on reaching the upper limit!



The gate type indicates the level of the system component within the event venue.

The Name is taken from the pre-configured component within the event venue.

The upper Limit determines the allowed maximum number of persons allowed in the area in question.

The lower Limit specifies the number to which the attendance total must drop before new admissions are allowed.

Entries / Exits indicate admissions, gate passages in entry and exit direction, and departures.

The listed counters can be edited but not deleted.

3.8.10 User counter

User counters work in much the same way as system counters, except that the number of user counters that may be defined is not limited.

User counters can be used to count only specific ticket properties within individual areas of the venue. These counters can be as-signed to the event venue, layouts, areas, events, access gates and checkpoints.

Fig. 115: System counter




The display structure for user counters is the same as for system counters.

3.8.10.1 Creating and editing counters

To set up or modify a new user counter, you can select and edit it. Note that system counters cannot be added.

3.8.10.2 Counter configuration

Counter configuration includes the following settings:

For system counters, the Name is taken from the component within the event venue. When setting up a user counter, you can specify a name here, which may be up to 30 characters in length.

Fig. 116: User counters

Fig. 117: Creating and editing counters



The upper Limit determines the allowed maximum number of persons allowed in the area in question (i.e., the quota).

The lower Limit specifies the number to which the attendance total must drop before new admissions are allowed.

Entries / Exits indicate admissions, gate passages in entry and exit direction, and departures. Entry and exit counters cannot be edited. Also, they are only reset at the specified Reset Time.

If Reset at Limit is activated, the counter is automatically reset when the limit is reached, and no blocking action will be per-formed.

Since different counters can be assigned to the same location, a standard counter can be set by activating the display counter readings at locations option. This will be the counter whose readings will be shown on the reader display. Once this counter reaches the pre-set upper limit, either the default blocking action "Counter: Admission limit exceeded (150)" or the custom defined blocking action is performed.

The Idle action determines the checkpoint message, and the light and sound signal for normal (‘standard’) gate passages. Idle actions can be edited in the same way as actions.

The specified Blocking action is activated when the upper at-tendance limit is reached. A special display text, as well as light and sound signals can be used to indicate this condition. Block-ing actions can be edited in the same way as regular system ac-tions.

Note: This menu lets you only create Idle and Blocking ac-tions. To edit or delete them, you must go to the “Actions” menu.

Fig. 118: Creating a Idle action




Verification period determines the time when the counter ap-plies. If no time period is set, the counter applies at all times.

Resetting Time indicates the date and time when the counter should be reset to 0. All counters are reset automatically at 12am midnight.

To reset the counter using a Reset Control Card, you can select an existing one or create new one (see 3.8.4.4 Control functions).

3.8.10.3 Assigned locations

The assigned location has to be selected, when setting up a user counter.

User counters can be created for the following parts of the event venue:

Entire event venue Layouts Areas Events Gates Checkpoints

To assign a location, select the Location Type option and use the arrows > (>> to assign all) to assign the locations.

Fig. 119: Assigned locations



3.8.10.4 Assigned identifications

User counters can be created for specific ticket properties. Sys-tem counters, on the other hand, always count all gate passages.

The list of assigned identifications contains the ticket properties (see 3.7.6 Properties).

To select a ticket property (identification), right-click in the lower area of the dialogue window, then click on Add New Group and activate the ticket properties to be counted by the user counter.

3.8.11 Blacklist

A blacklist is a list of blocked data carriers and permissions. The blacklist is usually transferred automatically from the ticket sys-tem. If necessary, it can also be created manually. Data carrier blocks relate to single tickets on specific data carriers that are recognized by the data carrier identification number. The blocking of permissions, on the other hand, refers to the properties of a ticket. As a result, setting up a permission block first the ticket number is entered and the ticket properties are looked up. Exam-ple: Suppose a contactless data carrier (keycard) contains per-missions for diverse events. Permission blocks can be set up for several time periods.

Fig. 120: Assigned identifications




When a data medium block is enforced, the entire data car-rier as such is blocked, which means it is no longer valid for existing event.

A permission block allows you to block (i.e., invalidate) the single permission on the data medium, so it is blocked only for a specific event while leaving it valid for all others.

3.8.12 Data medium blocks

The list of Current data medium blocks shows all cards that are currently blocked. Lists with more than 50 items can be filtered in accordance with specific blacklist entries.

Procedure for entering or editing data carrier blocks:

Fig. 121: Data carrier blocks



Specify the Ticket number of the data carrier to be blocked and select the Coding.

You can select any of the following Blocking reasons:

Ticket blocked Ticket stolen Ticket lost Ticket deleted Ticket renewed Ticket not paid Season pass not renewed Ticket was exchanged Substitute ticket Terminated

For the display at the checkpoint (Displaytext) you can enter a text message that will be displayed at the checkpoint if the black-listed ticket is used. This text may consist of up to 16 characters. You may also define an Alternate message; in that case the two screen messages will be displayed alternately at 2-second inter-vals; this can be used to realise multi-lingual welcome messages. Same settings can be made for the Operator message, if opera-tor displays are installed at the checkpoints.

The Comments helps to keep the particular data carrier block recognizable.

Data medium blocks are added with the blocked from, blocked until, and the expiration date.

Fig. 122: Blacklist data carrier




3.8.13 Permission blocks

Blocking permissions requires the specification of the ticket sys-tem, ticket number and data storage method.

Select the ticket system (Blocked) and Recording Method and enter the Ticket Number.

Hit the Find Permissions button to start the search for the re-cord. If a matching record is found, the corresponding ticket properties (permissions) will be displayed in a window.

Ticket properties marked with a green light bulb are valid; a red light bulb indicates a blocked permission.

Select the permission that you wish to block and click the New block button.

Fig. 123: Permission blocking

Fig. 124: Blocked permission



You can select any of the following blocking reasons:

Ticket blocked Ticket stolen Ticket lost Ticket deleted Ticket renewed Ticket not paid Season pass not renewed Ticket was exchanged Substitute ticket Terminated

For the display at the checkpoint (Displaytext) you can enter a text message that will be displayed at the checkpoint if the black-listed ticket is used. This text may consist of up to 16 characters. You may also define an Alternate message; in that case the two screen messages will be displayed alternately at 2-second inter-vals; this can be used to realise multi-lingual welcome messages. Same settings can be made for the Operator message, if opera-tor displays are installed at the checkpoints.

In the Comments input box you can enter keywords or remarks to make the blocking record easily traceable.

Permission blocks are added with the blocked from, blocked until, and the expiration date. When importing permission blocks, these dates are automatically included. More than one time period can be added to a permission block. Therefore add several blocks with different time periods.

To remove a permission block, simply click on the Delete block button. To edit the block click on Edit block.

Fig. 125: New permission block


Journal 3.9


3.9 Journal

In case you need to know when, where and by whom the hand-shake™ configuration was modified, handshake™ Journal will supply all the required details. This is to allow you to track all op-erating activities effected through handshake™ Explorer down to the last detail. A range of search options are provided for gener-ating reports with respect to specific staff members, time periods, or system devices.

Lists with more than 50 items can be filtered in accordance with specific journal entries. When searching for special message texts, use the wildcard *.

The journal contains all information about the imports from the ticket system as well as all data about the ticket usage at the checkpoints. Further more all actions coming from the modules Monitor and Messaging are recorded.

Fig. 126: Journalization

3 Handshake.Logic – Explorer 3.10 Test mode


3.10 Test mode

The test mode works with real issued tickets. The transaction data created during the test period are marked. When leaving test mode, you can decide whether or not the test data created during your testing session should be converted to real data.

Note that any configuration changes made while in test mode will be retained, regardless of your decision regarding test data con-version. When the system is running in test mode, this is indi-cated in handshake™ Explorer and on the display at checkpoints.

When the system is running in test mode, this is indicated by the symbol in handshake™ Explorer. In test mode you can config-ure and modify the system in the same way as you would in nor-mal operating mode; there is no difference in functionality.

Note: All master data created or edited in test mode will be available in normal mode.

In Access Manager, you can see on the status bar if the system is running in test mode.

Fig. 127: Activated Test Mode


Test mode 3.10


Test mode is indicated on the checkpoint displays by an alternat-ing text message.

Information: If tickets are used in test mode, the corre-sponding data are not automatically included in the statistics. This means that there is no report data available during test mode.

As soon as more than one client are working on the same hand-shake™ System, the test mode is activated exclusively for the layout of the client the user has logged on to. Using more than one layout, the layout that should be switched to test mode has to be selected and is activated afterwards. The global overview of the event venue will show the layouts and the assigned areas. If a layout is switched to test mode, the mode is shown by the sym-bol in front of the layout.

Fig. 128: Access Manager: test mode

Fig. 129: Reader display: test mode

Fig. 130: Test mode multiple layout



3.10.1 Activating test mode (one layout)

Important: As the Handheld Terminal cannot detect test mode automatically, the test mode has to be activated manu-ally.

To activate test mode, simply click the symbol.

Clicking Yes will activate test mode. This will cause an automatic system synchronisation.

3.10.2 Activating test mode (more than one layout)

To activate test mode, simply click the symbol.

All defined layouts set up for the current client, are displayed in the layout list. Select the layout to switch in test mode and con-firm with OK. The test mode is activated and a synchronisation is executed automatically.

Fig. 131: Test mode activation dialogue

Fig. 132: Activate test mode


Test mode 3.10


3.10.3 Deactivating test mode (one layout)

When terminating test mode, you can decide whether or not the data records created in test mode should be converted to regular (i.e., ‘real’) data. You may also reset the counters as needed.

To deactivate test mode, simply click on the symbol.

Click Yes to confirm. This will bring up a message prompting you to decide whether the test data should be converted to regular data.

Yes If you decide to have the test data converted to regular data, the tickets used will be treated as regular (‘real’) tickets. This means that these tickets will then be registered as used tickets that can-not be used again for re-admission (e.g., in case of 1-day tickets). Also, the conversion to regular data will cause any gate transac-tion details to be included in the statistical charts and evaluations.

No Clicking “No” in the above dialogue will cause the records of any gate transactions effected during Test Mode to be erased. The tickets used during Test Mode can then be reused as needed.

Fig. 133: Test mode deactivation dialogue

Fig. 134: Test data conversion dialogue

Fig. 135: Reset the counters



To reset the counters to 0 confirm clicking on Yes.

When test mode is deactivated, the system will be synchronised automatically and is working in standard mode again.

3.10.4 Deactivating test mode (more than one layout)

To deactivate test mode, simply click on the symbol.

All defined layouts set up for the current client, are displayed in the layout list. Layouts switched to test mode are marked .

Select the layout to switch off the test mode and decide if you want to Rest counters and if to Delete test data or Convert test data into regular data.

Confirm with OK, the test mode is deactivated and a synchroni-sation is executed automatically.

Fig. 136: Deactivate test mode


Archive 3.11


3.11 Archive

When logging into the handshake™ Explorer the user may choose which database to view: the online database or the one restored from the archive.

This allows for bringing up action details that were previously de-leted. In addition, previous reports can be reprinted as needed.

The switch from Online to Archive mode is possible after the ini-tial creation of the archive database (see chapter 8 handshake™ – Archive).

By clicking the Archive Symbol within the handshake™ Explorer environment, the Archive database is activated. The data is visu-alized and can not be changed.

Fig. 137: Archive mode

3 Handshake.Logic – Explorer 3.11 Archive


Handshake.Logic – Reporter 4

4 Reporter


4 Handshake.Logic – Reporter 4.1 Contents


4.1 Contents

4.1 Contents 2

4.2 Reporter 3 4.2.1 Requirements and program operation 4 4.2.2 Error message 6

4.3 Admission statistics 7 4.3.1 Admission statistics – Total 8 4.3.2 Admission statistics – Comparison 11 4.3.3 Fill level – visitors 13

4.4 Visitor frequency analysis 15 4.4.1 Visitor Frequency analysis – Day analysis 16 4.4.2 Visitor frequency analysis – Period analysis21

4.5 Length of stay 25 4.5.1 Length of stay 26

4.6 Irregularities 30 4.6.1 Occurred error codes 30 4.6.2 Details 32 4.6.3 Restrictions 34 4.6.4 Categories 36

4.7 Ticket Data 38 4.7.1 Ticket use 38 4.7.2 Ticketdata 40 4.7.3 Whitelistdata 42


Reporter 4.2


4.2 Reporter

The automated ticket control system provides the operator with valuable data for improving visitor safety and planning targeted marketing measures.

The Reporter can be used to generate detailed lists and statisti-cal charts from the transaction records.

To maximize operational flexibility, the Reporter can be launched from any PC-based workstation within the network.

Users can retrieve information about the handshake™ System simply by connecting to the handshake™ server via Microsoft Internet Explorer.

An authorization administration feature provides safe access management and user control functions for the handshake™ server.

The Reporter supports for the following statistical evaluations:

Admission statistics Frequency analyses Length of Stay statistics Irregularity statistics Ticket usage statistics

4 Handshake.Logic – Reporter 4.2 Reporter


4.2.1 Requirements and program operation

In order to be able to use the Reporter, the user role "Report Manager" must be assigned to the user (see chapter 3 hand-shake™ Explorer 3.4.2 User Administration).

Following statistical evaluations can be selected:

Admission statistics – report manager Visitor frequency analysis – report manager Length of stay – report manager Irregularities – special report manager Ticket data – special report manager

The report layout can be constructed from main criteria ( + ), possible filter criteria ( + + + ), and, if required, a selec-tion of sorting criteria ( + ).

The report is displayed in a separate window. Note that it is pos-sible to generate multiple reports and work with one while leaving the others open in the background.

Fig. 1: Creating a report


Reporter 4.2


The title bar of the frame shows the name and the content of the report. The header of the report shows the main criteria ( + ), the name of the client (SKIDATA AG), the date of evaluation (07.04.2003 9:57:24) and the windows 2000 login name of the user (DIUL) creating the report, as well as the filter criteria ( +

) and the sorting order ( ).

Following functions can be executed with the help of the symbols in the symbol bar:

Print report

Export report (possible file formats: Crystal Reports 8 / 7 *.rpt, Microsoft Excel *.xls, Microsoft Word *.doc, Rich Text For-mat *.rtf, Adobe Acrobat *.pdf)

Refresh data

Toggle Group Tree

Zoom in / out

Fig. 2: Report

4 Handshake.Logic – Reporter 4.2 Reporter


, Go to First Page, Go to Previous Page

Page Number, Number of Pages

Go to last Page, Go to Next Page

Search Text

4.2.2 Error message

In case no data is found to match the specified criteria, the follow-ing error message is displayed:

Close the message window, check your selection criteria and cor-rect them if necessary.

Fig. 3: Error message


Admission statistics 4.3


4.3 Admission statistics

Admission statistics are statistical analyses covering completed admissions to events, areas, or venues. An admission in this case means the successful passage through a checkpoint. This is recorded as a successful ticket authentication, a manual turn-stile release, and the passage through a checkpoint running in free passage mode.

The counters are increased after each successful gate admis-sion. The following counters are available for inclusion in admis-sion statistics reports:

Entries – counts successful ticket checks and passages, ad-missions by manual turnstile release and entries during check-point operating mode permanent free in entry direction.

Exits – counts successful ticket checks and passages, admis-sions by manual turnstile release and entries during check-point operating mode permanent free in exit direction.

First Entries – counts successful ticket checks and passages with tickets that are used for the first time. Depending on the specified selection, this counter will show the first use of the ticket for accessing the event venue, a pre-defined area or the event.

First Entries at Day – counts successful ticket checks and passages for tickets being used for the first time on the current date. Depending on the specified selection, this counter will show the first use of the ticket for accessing the event venue, a pre-defined area or the event.

When defining upper limits for the event venue or areas within the handshake™ explorer, reports showing the current fill limit of the actual day related to the set upper limit can be selected.

4 Handshake.Logic – Reporter 4.3 Admission statistics


4.3.1 Admission statistics – Total

The Total of access statistics provides a consolidated list of ex-isting records and transforms this into reports in accordance with specified selection criteria. After selecting the Event-, Area or Venue counters (menu on the left side) the main criteria for the report can be selected.

Date – lists all dates on which passages have been regis-tered.

Event– lists all event-specific passages, during the pre-defined event time and assigned event areas. (see chapter 3, 3.8.2 Events).

Area – counts all passages into the defined areas (see chap-ter 3, 3.5.4 Areas).

Venue – counts all passages into the defined venue (see chapter 3, 3.5.2 Event Venue).

Checkpoint – lists all used checkpoints, for which passages have been registered.

Gate – lists all used gates, for which passages have been reg-istered.

Ticket property – lists all ticket properties for which passages where registered (see chapter 3, 3.7.6 ticket properties).

Permission type – lists all permission types for which pas-sages where registered (see chapter 3, 3.8.3 ticket proper-ties).

Fig. 4: Admission statistics – Total




To create the report for specified data, e.g. a special time period and area, the selection criteria can be used.

Depending on the selected filter criteria, those are shown after click on the Proceed button.

After the click on the Proceed button, the sort order for the ad-mission statistic can be selected.

When clicking on the button Report, the report is created de-pending on the pre-selected criteria's.

Fig. 5: Selection of filter criteria

Fig. 6: Selection of filter criteria

Fig. 7: Sort order



Fig. 8: Admission statistics report




4.3.2 Admission statistics – Comparison

The Comparison view of access statistics shows a comparison of existing records and includes them in the report in accordance with specified selection criteria.

After selecting the Event-, Area or Venue counters (menu on the left side) the main criteria for the report can be selected.

Within the selected shown criteria (e.g. Date), additionally the fol-lowing comparison can be selected

Date Checkpoint Gate Venue Ticket property Permission type

The shown report, will list the main criteria compared by the se-lected comparison type.

To create the report for specified data, e.g. a special time period and area, the selection criteria can be used (see 4.3.1 Admission statistics – Total).

Fig. 9: Admission statistics – Comparison



Fig. 10: Admission statistics – Comparison




4.3.3 Fill level – visitors

The Fill Level report shows the occupancy percentage of the event venue or of the areas. Therefore the fill limit has to be de-fined during the venue configuration within the handshake™ ex-plorer.

The Shown criteria for the report can be the Area or the Venue.

Fig. 11: Fill level – visitors



Depending on the set fill level, the current number of visitors re-lated to the Maximum is shown.

Note: This report shows the number of visitors for the current day.

Fig. 12: Fill level


Visitor frequency analysis 4.4


4.4 Visitor frequency analysis

The analysis function allows for the evaluation and analysis of visitor frequency details registered at checkpoints.

The statistics indicate completed admissions to events, areas, or venues. An ‘admission’ means an instance of passing through a checkpoint gate. This is recorded as a successful ticket authenti-cation, a manual turnstile release, and the passage through a checkpoint running in Free Passage mode.

The main criteria for creating frequency analyses include the fol-lowing:

Event counters – lists all event-specific access transactions. These include all admissions to designated event areas during the pre-specified time period (for details see Section 3, 3.8.2 Events).

Area counters – counts only area-specific admissions, i.e., admissions to designated areas (for details see Section 3, 3.5.4 Areas).

Venue counters – covers only venue-specific admissions, i.e., admissions to designated event venues (for details see Section 3, 3.5.2 Event Venue).

4 Handshake.Logic – Reporter 4.4 Visitor frequency analysis


4.4.1 Visitor Frequency analysis – Day analysis

The Day analysis provides an analysis of visitor frequencies on a per-day basis.


Event– lists all event-specific passages, during the pre-defined event time into the event venue (see chapter 3, 3.8.2 Events).

Area –lists all passages into the defined areas (see chapter 3, 3.5.4 Areas).

Venue – lists all passages into the defined venue (see chapter 3, 3.5.2 Event Venue).



Ticket property – lists all ticket properties for which passages where registered (see chapter 3, 3.7.6. ticket properties).

Permission type – lists all permission types for which pas-sages where registered (see chapter 3, 3.8.3. Permission types).

no comparison – no comparison will be executed.

Fig. 13: Visitor frequency analysis – day analysis




The following access counters can be included in the frequency analysis report:


Day First Entry – counts successful ticket checks and pas-sages for tickets being used for the first time on the current date. Depending on the specified selection, this counter will show the first use of the ticket for accessing the event venue, a pre-defined area or the event.

Entries – counts successful ticket checks and passages, ad-missions by manual turnstile release and admissions in checkpoint operating mode Free Passages in entry direction.

Exits – counts successful ticket checks and gate passages, admissions by manual turnstile release, admissions in check-point operating mode Free Passages in exit direction.

Current Number of Visitors – this indicates the number of ingress transactions less the number of egress transactions

The Period defines, how detailed the report should be created

15 minutes 30 minutes 1 hour 2 hours 3 hours

To create the report for specified data, e.g. a special time period and area, the selection criteria can be used.

When using the visitor frequency analysis – day analysis, the day to be shown can be selected. Therefore click on the selection ar-row of the date to se the system calendar.



When selection criteria's have been selected, the details have to be selected on this site.

A maximum of 13 elements can be shown within the frequency analysis (e.g. checkpoints, days etc.). When selecting suppress residual columns, the rest of the values are not shown.

Clicking on the Report button, will bring the report depending on the selected criteria's.

The analysis report consists of min. 3 pages.

Fig. 14: Selection of day

Fig. 15: Number of shown criteri-as




The cover page, Page 1, provides details about selected criteria and the time when the analysis is prepared. A tabular listing of the selected admission counter readings at the specified interval (15 or 30 minutes or 1 to 3 hours) is shown.

Fig. 16: Page 1 Visitor frequency analysis – Day analysis



Page 2 shows a line chart of selected admission counter read-ings for each main criterion.

Page 3 provides a sum total of the selected access counter.






4.4.2 Visitor frequency analysis – Period analysis

The Period analysis provides an analysis for a custom-definable period, with comparisons for individual days.


The following Access counters can be included in the frequency analysis report:


Day First Entry – counts successful ticket checks and pas-sages for tickets being used for the first time on the current date. Depending on the specified selection, this counter will show the first use of the ticket for accessing the event venue, a pre-defined area or the event.

Entries – counts successful ticket checks and passages, ad-missions by manual turnstile release and admissions in checkpoint operating mode Free Passages in entry direction.

Exits – counts successful ticket checks and gate passages, admissions by manual turnstile release, admissions in check-point operating mode Free Passages in exit direction.

Fig. 19: Visitor frequency analysis – Period analysis



Current Number of Visitors – this indicates the number of ingress transactions less the number of egress transactions



To create the report for specified data, e.g. for several days, the selection criteria can be used. Depending on the selected crite-ria's, it can be selected after clicking on the Proceed button.

For the frequency analysis period analysis the single days for the analysis can be selected one by one. An analysis for in total 14 days is shown by default. To select the days with the help of the calendar, click on the selection arrow of the date.

A maximum of 13 elements can be shown within the frequency analysis (e.g. checkpoints, days etc.). When selecting suppress residual columns, the rest of the values are not shown.


The analysis report consists of min. three pages:

Fig. 20: Selection of several days





Fig. 21: Page 1 Visitor frequency analysis – Period analysis



Page 2 shows a line chart of selected admission counter read-ings for each day.

Page 3 provides a sum total of the selected access counter.




Length of stay 4.5


4.5 Length of stay

The stay duration statistics provides information about the aver-age time spent at events, or in specific areas or venues.

To ensure that the supplied information is accurate, the statistics routine requires a check-in/check-out system (i.e., a system that can be used for both ingress and egress). If such a system is not available, the stay duration statistics will be based on the pre-set end-of-day time as the exit time.

The main criteria for creating stay duration statistics include the following:

Event counters – lists all event-specific access transactions. These include all admissions to designated event areas during the pre-specified time period (for details see Section 3, 3.8.2 Events).

Area counters – counts only area-specific admissions, i.e., admissions to designated areas (for details see Section 3, 3.5.4 Areas).

Venue counters – covers only venue-specific admissions, i.e., admissions to designated event venues (for details see Section 3, 3.5.2 Event Venue).

4 Handshake.Logic – Reporter 4.5 Length of stay


4.5.1 Length of stay

The length of stay statistics calculates the average duration of stay (from entry to exit) from Day begin to End of day and com-pares it depending on the selected criteria's.


Date – lists all dates on which passages have been regis-tered.

Venue – counts all passages into the defined venue (see chapter 3, 3.5.2 Event Venue).

Event– lists all event-specific passages, during the pre-defined event time and assigned event areas. (see chapter 3, 3.8.2 Events).

Area – counts all passages into the defined areas (see chap-ter 3, 3.5.4 Areas).



Ticket property – lists all ticket properties for which passages where registered (see chapter 3, 3.7.6 ticket properties).

Fig. 24: Length of stay


Length of stay 4.5


Permission type – lists all permission types for which pas-sages where registered (see chapter 3, 3.8.3 permission types).

no selection – no comparison will be executed.



For the length of stay statistic the Day begin and the end of day time must be set

Day begin defines the start time for the calculation End of day defined the end time for the calculation


As the length of stay report is a graphical report, a maximum of 10 elements can be shown within (e.g. checkpoints, days etc.). When selecting suppress rest columns, the rest of the values are not shown.

The analysis report consists of two pages.

4 Handshake.Logic – Reporter 4.5 Length of stay



Fig. 25: Page 1 Length of stay


Length of stay 4.5


Page 2 shows a bar chart of the calculated average length of stay per day.



4 Handshake.Logic – Reporter 4.6 Irregularities


4.6 Irregularities

Irregularities are all situations at the checkpoints where standard ticket authentication or gate passages are impossible for some reason. ‘Standard ticket authentication’ here means a gate pas-sage granted on the basis of positive ticket verification.

There are four basic irregularity analyses:

Occurred error codes – Provides an overview of encoun-tered irregularities, sorted by frequency.

Details– This lists all encountered irregularities grouped by selected criteria.

Restrictions – Provides an analysis of irregularities due to re-strictions (ticket authentication).

Categories – Provides an analysis of irregularities

4.6.1 Occurred error codes

Depending on the shown criteria selected, the frequency of en-countered irregularities will be shown with respect to that crite-rion.

Fig. 28: Irregularities – Occurred error codes


Irregularities 4.6


The Comparison by setting, defines the sub criteria the report should be based on.

A maximum of 13 elements can be shown within the frequency analysis (e.g. checkpoints, days etc.). When selecting suppress rest columns, the rest of the values are not shown.

To get clear information from the report, it makes sense to select some filter criteria e.g. predefined time period – today.

This report includes only actual irregularities encountered in indi-vidual components (Server, Access Manager, and Checkpoint).

Displayed irregularities are listed by frequency (see Chapter 5 5.5.1.0 Possible Emergency Operation Situations and Chapter 3, 3.8.7 Error Actions).

Fig. 29: Irregularities – Occurred error codes



4.6.2 Details

Depending on the criterion selected (Shown criteria), the fre-quency of encountered irregularities will be shown with respect to that criterion.



This report does not include successful standard gate passages, but only irregularities as they occurred.

Fig. 30: Irregularities – Details


Irregularities 4.6


This shows all possible irregularities at the checkpoints (see Sec-tion 3.8.7 Error Actions for details) for the selected time in accor-dance with the selected main criterion.

Fig. 31: Irregularities – Details



4.6.3 Restrictions

Depending on the Shown criteria selected, the frequency of en-countered irregularities will be shown with respect to that crite-rion.



Fig. 32: Irregularities – Restrictions


Irregularities 4.6


The Admission Configuration dialogue allows you to define re-strictions (see Chapter 3, 3.8.4.3 Restrictions), e.g., for re-admission to the venue, double-use waiting time in entry direc-tion, etc. If a specified restriction applies (e.g., readmission not al-lowed), the corresponding irregularities are recorded in this report.

Fig. 33: Irregularities – Restrictions



4.6.4 Categories

Depending on the criterion selected (Shown criteria) the fre-quency of encountered irregularities will be shown with respect to that criterion.



Fig. 34: Irregularities – Categories


Irregularities 4.6


The list of irregularities is organised into groups:

Ticket not valid – shows all used ticket, which were not al-lowed to pass e.g. unknown ticket, access denied etc.

Ticket blocked – counts the used tickets, which were listed in the blacklist and therefore not allowed to enter.

Ticket valueless – if a ticket is no longer valid, because its value is used up, it will be counted in this category.

Counter limit reached – predefined counters have been reached, the corresponding error message has been shown at the gates.

Blocking times apply – defined restrictions, which denies e.g. the double use of tickets apply.

Ticket usages – each time a ticket is reused although not al-lowed, this counter is increased.

System error Control card usages – shows the usage of control cards. Manual releases – shows all manual releases through the

access manager, monitor or through control card.

Fig. 35: Irregularities – Categories

4 Handshake.Logic – Reporter 4.7 Ticket Data


4.7 Ticket Data

The Ticket Data analysis provides a ticket usage history, covering both gate passages and rejections, for each individual ticket. The resulting report lists all instances of ticket use throughout the sys-tem, including transactions at checkpoints, for each individual ticket.

Note: Please note that these reports may contain a consider-able amount of data. It is therefore recommended to create re-ports of this type only for specific checkpoints or tickets.

4.7.1 Ticket use

The Ticket use report shows all ticket usages within the system. All ticket usages separated by the single ticket at the checkpoints are shown.

The report of the ticket usages can be listed compared by em-ployees (Comparison by setting). The report is than created by ticket usage employee related. Employees are used to log on to the Handheld Application Soft Pinpad and Monitor.

Fig. 36: Ticket Data – Ticket use


Ticket Data 4.7


To show the usage of exactly one ticket, select the filter criteria Ticket ID.

The ticket ID can be requested directly in the ticketing system or is printed on the ticket.

The report shows each single transaction of the ticket, including the actions on the single checkpoints.

Fig. 37: Ticket ID from – to

Fig. 38: Ticket Data – Ticket use



4.7.2 Ticketdata

Additional to the single ticket usage information, the Ticketdata report shows the permission type and the ticket property of the used ticket.


To get clear information from the report, is makes sense to select some filter criteria e.g. Ticket ID.

The ticket ID can be requested directly in the ticketing system or is printed on the ticket.

Fig. 39: Ticket Data – Ticketdata

Fig. 40: Ticket ID from – to


Ticket Data 4.7


The left side in the frame shows the selected comparison by cri-teria and the time detail of the ticket usage. For each usage of the ticket, the ticket data is recorded.

Fig. 41: Ticket Data – Ticket data



4.7.3 Whitelistdata

The whitelist contains information about the sold and used tick-ets. The report of the Whitelistdata shows all tickets stored in the whitelist.

To be able to search the whitelist, the for reporter available ticket properties or the Ticket ID can be used as filter criteria. The ticket ID can be requested directly in the ticketing system, is printed on the ticket.

Fig. 42: Ticket Data – Whitelistdata

Fig. 43: Selection of event


Ticket Data 4.7


The whitelistdata report shows all existing ticket data (sold tick-ets) imported by the Ticketing System and references to the blacklist (blocked tickets).

The TS-Property value and the TS Property type are figures from the ticketing system and are mapped to handshake™ Identifiers and ticket properties (see chapter 3, 3.7.6 Properties).

As handshake™ has an interface to the ticketing partners, this report is helpful to find out the successful transfer of whitelist data for each event.

Fig. 44: Ticket Data – Whitelistdata



Handshake.Logic – Access Manager 5

5 Access Manager


5 Handshake.Logic – Access Manager 5.1 Contents


5.1 Contents

5.1 Contents 2

5.2 Access Manager 3

5.3 Start 4

5.4 Screen layout 5 5.4.1 Menu bar 5 5.4.2 Tool bar 6 5.4.3 Checkpoint window 6 5.4.4 Status bar 6

5.5 Checkpoint window 7 5.5.1 Transactions 7 5.5.1.1 Emergency mode 8 5.5.1.2 Possible emergency operation situations 8 5.5.1.3 Access Manager and checkpoint messages 9 5.5.2 Control functions 11 5.5.3 Statistics counters 13 5.5.4 Arranging the checkpoint windows 14 5.5.5 Changing checkpoint window size 15


Access Manager 5.2


5.2 Access Manager

The Access Manager includes all processes required to evaluate the tickets and control the access terminals. The Access Man-ager can be used to manage several venues such as halls, sta-diums and visitor areas in parallel.

The very special thing about Handshake.Logic is the fact, that all checks are done completely flexible depending on ticket and ticket technology.

The decentralised Access Manager has two basic key functions:

to provide the functionality of a “hardware hub” in configura-tions where the readers are networked via Arcnet connec-tions, up to 8 checkpoints are connected to one Access Manager.

to relieve the server by taking on part of the processing load in configurations involving Ethernet-based readers or a large number of gates

5 Handshake.Logic – Access Manager 5.3 Start


5.3 Start

The Access Manager process starts automatically after turning on the computer. To get to the graphic user interface, click Start – Access Manager.

The Access Manager will be in standby mode, At this stage, no interaction with the connected checkpoints is possible. The standby mode The standby mode is strictly for monitoring events at the checkpoints.

Each checkpoint is displayed in a separate window.

Fig. 1: Standby mode

To actively interact with the connected checkpoints, select Sys-tem from the menu and click Login.


Screen layout 5.4


5.4 Screen layout

5.4.1 Menu bar

To enter the desired menu in the menu bar, press the ALT key and the underlined character of the title or press F10, Menus are selectable without the use of a mouse.

Fig. 2: Main screen

Fig. 3: Menu bar

5 Handshake.Logic – Access Manager 5.4 Screen layout


5.4.2 Tool bar

With the symbols in the tool bar, you control the layout of the in-dividual check point windows. The commands executable via the tool bar are in the menus Window, View and Settings.

5.4.3 Checkpoint window

In the check point window, the ticket evaluation status is dis-played. Turnstiles can be opened manually, the checkpoint mode can be changed and the light signal can be influenced. The counters for access statistics are displayed.

Which checkpoints are available is determined in handshake™ Explorer.

5.4.4 Status bar

In the status bar, system information and error messages are dis-played. On the far left, there is information about whether the user is logged in and when login was performed. in the right cor-ner, time and date are displayed.

Fig. 4: Tool bar

Abb. 5: Checkpoint window

Fig. 6: Status bar


Checkpoint window 5.5


5.5 Checkpoint window

5.5.1 Transactions

All information about successful ticket evaluations or rejects for particular causes is displayed here. The display can be altered in the menu Display Irregularities, Passage, Output Stopped. If A in front of one of these points shows that is activated.

Ticket inspection is displayed thus:

At the start of Access Manager, the following information is dis-played in the checkpoint window:

TT.MM.YYYY HH:MM:SS INFO Check Engine On-line TT.MM.YYYY HH:MM:SS INFO Deactivate Emergency Mode

The checkpoint is on line and displays

The Standard Display Message can be changed in the hand-shake™ Explorer (see 3.5.2.2. Checkpoint default behaviour)

Fig. 7: Checkpoint transactions

Tab. 1:Access Manager transaction display

Current Date / Time Ticket Number

Message Status Message Text

TT.MM.YYYY HH:MM:SS ########## OK / INFO / ERR Information or Error Message

Fig. 8: Checkpoint standard dis-play message

5 Handshake.Logic – Access Manager 5.5 Checkpoint window


5.5.1.1 Emergency mode

The messages at the Access Manager and at the checkpoint are the same for all emergency operation situations. Ticket transac-tions performed during emergency operation are transmitted to the Access Managers when connection is re-established.

If and when emergency operation occurs, the Access Manager displays a message. Unless configured differently by the opera-tor, the checkpoint semaphores are turned off and a message is shown on the reader’s display.

When the problem has been solved, data collected during emer-gency operation is transmitted to the Access Manager, and the checkpoint resumes on line operation.

5.5.1.2 Possible emergency operation situations

ARCNET Service is stopped Start the ARCNET Service at the Access Manager.

Access Manager Process is stopped (PC has been turned off) Turn on the Access Manager Computer

Connection between checkpoint and Access Manager is inter-

rupted Check connection to the Access Manager PC and check,

whether the Access Manager PC is turned on.

Server connection has been interrupted Check server connection and check, whether the server is

turned on.

Access Manager Checkpoint ERR Activate Emergency Mode PLEASE INSERT

TICKET

Access Manager Checkpoint INFO Deactivate Emergency Mode SYSTEM SKIDATA

TT.MM.YYYY HH:MM




5.5.1.3 Access Manager and checkpoint messages

The messages displayed by the Access Manager are reflected by appropriate concurrent messages displayed by the checkpoint it-self. (see chapter 3, 3.8.7 Error actions)

Tab. 2: Access Manager and standard checkpoint display messages

Access Manager Checkpoint Meaning OK WELCOME Ticket was inspected and accepted. ERR Check Engine Offline PLEASE INSERT

TICKET During the start phase and when connection to the server can not be established, the Check Engine is off line

INFO Check Engine Online SYSTEM SKIDATA TT.MM.YYYY HH.MM

Check Engine has been started, the check-point is in online mode.

ERR Out of Order on PLEASE INSERT TICKET

During the start phase and when connection to the server can not be established, the checkpoint is in emergency operation mode.

INFO Out of Order off SYSTEM SKIDATA TT.MM.YYYY HH.MM

The checkpoint has connection to the server and is in online mode.

INFO Manual release WELCOME Manual turnstile opening was performed. ERR Checkpoint permanent free FREE PASSAGE

TT.MM.YYYY HH.MM A ticket was used while the checkpoint is in permanent open mode.

ERR Checkpoint blocked NO ENTRY TT.MM.YYYY HH.MM

A ticket was used while the checkpoint is in blocking mode.

ERR Todays Area entries ex-ceeded

TODAYS AREA ENTRIES EXCEEDED

The maximum daily number of re-admissions to the specified area has been exceeded.

ERR Area entries exceeded AREA ENTRIES EXCEEDED

The maximum number of re-admissions to the specified area has been exceeded.

ERR Area re-entry waiting period AREA RE-ENTRY WAITING PERIOD

The waiting period for re-admission to the area has not yet elapsed.

ERR Area double usage in entry direction not allowed

AREA ENTRY DOUBLE-USAGE NOT ALLOWED

The waiting period for re-using the ticket to enter the specified area has not yet elapsed.

ERR Area re-exit waiting period AREA RE-EXIT WAITING PERIOD

The waiting period for re-admission to the specified area has not yet elapsed.

ERR Area double usage in exit direction not allowed

AREA EXIT DOUBLEUSAGE NOT ALLOWED

The waiting period for re-using the ticket to exit the specified area has not yet elapsed.

ERR Todays Event entries ex-ceeded

TODAYS EVENT ENTRIES EXCEEDED

The maximum daily number of re-admissions to the event has been exceeded.

ERR Event entries exceeded EVENT ENTRIES EXCEEDED

The absolute maximum number of re-admissions to the event has been exceeded.

ERR Event re-entry waiting period EVENT RE-ENTRY WAITING PERIOD

The waiting period for re-admission to the event has not yet elapsed.




Access Manager Checkpoint Meaning ERR Event double usage in entry direction not allowed

EVENT ENTRY DOUBLE-USAGE NOT ALLOWED

The waiting period for re-using the ticket for re-admission to the event has not yet e-lapsed.

ERR Event re-exit waiting period EVENT RE-EXIT WAITING PERIOD

The waiting period for re-exiting the event has not yet elapsed.

ERR Event double usage in exit direction not allowed

EVENT EXIT DOUBLEUSAGE NOT ALLOWED

The waiting period for re-using the ticket to exit the event has not yet elapsed.

ERR Ticket not readable TICKET NOT READABLE

The system was unable to read the data stored on the ticket.

ERR Ticket not known in system TICKETTYPE UNKNOWN The ticket has an unknown format (CDF input parameter)

OK Control card accepted CONTROL CARD ACCEPTED

The control function to be checked for does exist on the ticket in question and is acti-vated.

ERR Ticket Data saving failed TICKET NOT ALLOWED INTERNAL ERROR

The system was unable to store the data read from the ticket.


The access permission to check for does not exist on the ticket in question; the ticket hol-der is denied access.


The non-permission to be checked for ap-plies to the ticket in question.

ERR Ticket value expired TICKET VALUELESS There are no more day credits available on the ticket for the permission in question.

ERR Ticket unknown TICKET UNKNOWN The permission to be verified is not included in the whitelist (whitelist clearance is required as per CDF configuration)

ERR Permission type unknown PERMISSION TYPE UNKNOWN

There is no verification type defined for veri-fying the ticket in question.

ERR Ticket not valid TICKET NOT VALID

Verification of the ticket’s validity yielded a negative result (the validity date is not in-cluded in the whitelist).

ERR Datamedium is blocked DATAMEDIUM BLOCKED

A blacklist entry exists for the data carrier in question. The data carrier has been blocked.

ERR Permission is blocked PERMISSION BLOCKED

Indicates that a blacklist entry exists for the permission in question. The permission will be blocked.


The ticket in question does not meet the condition being checked for.

ERR Ticket has not enough points %D% POINTS REQUIRED

The required number of points could not be deducted due to an insufficient point credit.

ERR Point Ticket valueless NO POINTS LEFT There are no more point credits available on the ticket for the permission in question.




5.5.2 Control functions

In this area of the checkpoint window, manual opening can be performed, the state of the checkpoint can be altered or the semaphore function changed. You can also switch the passage direction here.

By clicking the button System Sector C, a manual turnstile re-lease is performed. In the transaction list, the information INFO Manual release appears. Manual turnstile releases can also be


Access Manager Checkpoint Meaning ERR timeout VERIFICATION TIMEOUT Indicates that the time credits of the time

debit card have been used up. ERR Counter: Admission limit exceeded

ADMISSION LIMIT EXCEEDED

The pre-set attendance limit has been reached; the turnstile locks until the atten-dance drops below the pre-set level.

ERR Todays Venue entries ex-ceeded

TODAYS VENUE ENTRIES EXCEEDED

The maximum daily number of re-admissions to the specified venue has been exceeded.

ERR Venue entries exceeded VENUE ENTRIES EXCEEDED

The absolute maximum number of re-admissions to the event venue has been exceeded.

ERR Venue re-entry waiting period VENUE RE-ENTRY WAITING PERIOD

The waiting period for re-admission to the venue has not yet elapsed.

ERR Venue double usage in entry direction not allowed

VENUE ENTRY DOUBLEUSAGE NOT ALLOWED

The waiting period for re-using the ticket to enter the venue has not yet elapsed.

ERR Venue re-exit waiting period VENUE RE-EXIT WAITING PERIOD

The waiting period for re-exiting the specified venue has not yet elapsed.

ERR Venue double usage in exit direction not allowed

VENUE EXIT DOUBLEUSAGE NOT ALLOWED

The waiting period for re-using the ticket to exit the venue has not yet elapsed.

ERR time limit exceeded TIME LIMIT EXCEEDED

The time credit of the ticket has exceeded

ERR time ticket already entered TIME TICKET ALREADY ENTERED

The ticket used at the entry gate has been already used for entry.

ERR time ticket already left TIME TICKET ALREADY EXIT

The ticket used at the exit gate has been already used for exit.

ERR time ticket not entered yet TIME TICKET NOT ENTERED

The ticket used at the exit gate has been not used for entry.

Fig. 9: Control functions



performed via the menus Entrance and Exit with the instruction Manual release.

To change the checkpoint mode, a mode from the list ( )is se-lected and clicked. The Checkpoint mode is changed. There are 5 checkpoint modes: Free Passage, Ticket Check, Blocked, Out of Service and Permanent Open (only ADA-tursntiles).

The light signal can be toggled by clicking the signal button or via the menus Entry and Exit with the instruction Switch signal light.

Lights off

Green lights

Green lights flashing

Red lights

Red lights flashing

Red and green lights flashing simultaneously

Red and green lights flashing alternately

Yellow light (only three colour signal light)

Yellow light flashing (only three colour signal light)

No Connection

To switch the direction, simply click on the corresponding button:

Checkpoint checking in entry direction

Checkpoint checking in exit direction




5.5.3 Statistics counters

In the counters area, a summary of all ticket actions is kept up to date.

Fig. 10: Counters

Table 5: Counters for all tickets

Designation Meaning Day Entry / Exits All Entries / All Exits Manual release OK Number of manual openings invoked Entries by time out Number of entries during emergency operation of checkpoint. Free Passage Entry / Exit Number of transitions while checkpoint was in “free passage” mode +

number of additional openings in entrance / exit direction. Forced Entry / Exit Number of forced openings in entrance / exit direction. Permanent open entries / exits Number of transitions while checkpoint was in “permanent open” mode

+ number of additional openings in entrance / exit direction (only for ADA turnstiles).



5.5.4 Arranging the checkpoint windows

In the interest of optimal display settings, the arrangement of the checkpoint windows can be configured and saved. To get more room for the display of the checkpoints, the tool and status bars can be shown or hidden. The Tool Bar and the Status Bar can be found in the Activate menu. If a is shown at the front of ei-ther of them, the bar is activated.

Windows provides four views for the checkpoints.

displays active checkpoint windows in an overlapping ar-rangement (Menu Cascade View)

arrange active checkpoint windows vertically (Menu Split View Horizontally)

arrange active checkpoint windows horizontally (Menu Split View vertically)

Align symbols to the lower rim of the screen (Menu Rearrange View)

Selection of one of these symbols arranges the checkpoint win-dows accordingly.

In the symbol bar or in the Settings menu (Setting 1 through 4 - F11, F12, Shift F11, Shift F12), four dif-ferent views can be saved and retrieved.

When saving views, make sure to first select the view number (Symbol 1-4) and then arrange the checkpoint windows. Select

the save symbol , (Menu Settings Save) only after the ar-rangements are made. The current view is then designated one of the four symbols.

With this symbol (Menu Settings Recover - F9), the last saved view setting can be recovered.




5.5.5 Changing checkpoint window size

There are 3 ways to alter the size of checkpoint windows:

Diagonal arrows at the window corners. You can make the window smaller or larger by holding and then dragging the check-point window frame upward, left, right or down with the mouse.

Split arrow between the areas within a checkpoint window. The areas within each checkpoint window can be made smaller or larger by holding and dragging with the mouse, which moves the borderline.

Double arrows at the rim of the checkpoint window. The whole checkpoint window can be made wider or narrower, taller or shorter. You can make the checkpoint window smaller or lar-ger by holding and dragging with the mouse.



Handshake.Logic – Messaging 6

6 Messaging


6 Handshake.Logic – Messaging 6.1 Contents

Seite 2 © SKIDATA AG, Version 3.0 / 1.0

6.1 Contents

6.1 Contents 2

6.2 Messaging 3

6.3 Installation and basic settings 4 6.3.1 Initial installation 4 6.3.2 Assigning user rights 5 6.3.3 Running the Messaging client 6 6.3.4 Basic settings 6

6.4 User interface and program operation 7 6.4.1 Screen layout 7 6.4.2 Creating a new messaging alert 9 6.4.3 ‘General’ tab 10 6.4.4 ‘Statistics’ tab 11 6.4.5 ‘Checkpoint / Access Manager / server’ tab12 6.4.6 ‘Counter’ tab 13 6.4.7 ‘Message’ tab 14 6.4.8 ‘Schedule’ tab 17 6.4.9 'Response' tab 19 6.4.9.1 Adding a response 20 6.4.9.2 Action type ‘execute command’ 20 6.4.9.3 Action type ‘record in eventlog’ 21 6.4.9.4 Action type ‘send text message’ 22 6.4.9.5 Action type ‘send e-mail’ 23 6.4.9.6 Action type "view in Monitor" 24 6.4.9.7 Editing a response 25 6.4.9.8 Testing a response 26


Messaging 6.2


6.2 Messaging

With Messaging, operators have a tool allowing to be informed about events on the access control side.

Without having to actively run reports or perform investigations, messages from the handshake™ system are automatically sent to the registered user (e.g. administrator).

To guarantee that each person receives only the messages rele-vant to them, different events, communication channels or recipi-ents can be configured.

Thus, messages can be sent if for instance the 10,000th visitor enters the stadium, or, specifically of interest to system adminis-trators, when the status of a checkpoint changes.

These messages are transmitted via the most appropriate me-dium, for instance mobile text messages, e-mail, log files, pop up windows, etc.

6 Handshake.Logic – Messaging 6.3 Installation and basic settings


6.3 Installation and basic settings

Before installing the Messaging client you will need to install the Microsoft .NET Framework environment (version 1.1). The .NET Runtime is not located under handshake™ Setup and must be installed separately. The Messaging process is installed auto-matically at the server when the handshake™ server setup is executed. The Messaging Client is the control instance for the messaging process at the server, and can be installed on every workstation within the network.

6.3.1 Initial installation

To install the Messaging client on a workstation, you will need the handshake™ Installation CD. Run Setup by double-clicking Setup.exe on the setup file (e.g. hsh-setup-V03.0.2246-en). This will launch a setup wizard that will guide you through the installa-tion procedure.

Important: You must have administrator rights to be able to install this program.

On the list of components to be installed, all available compo-nents are pre-selected for installation. You have to deselect any component that you do not want installed. To do so, click on the hard disc symbol in front of the component’s name (e.g., Server) and select “This feature will not be available” from the drop-down menu.

Fig. 1: Messaging setup


Installation and basic settings 6.3


To proceed with the installation, follow the directions of the setup wizard.

Once Setup completes, an icon with a link to the Messaging will be placed in the start menu.

6.3.2 Assigning user rights

To be able to launch Messaging, the logged-in user must have a user right. User rights can be assigned as needed via hand-shake™ Explorer.

User right “Passive monitoring and Messaging” allows the user to monitor system functions and to administrate the Mes-saging module.

Fig. 2: User rights

6 Handshake.Logic – Messaging 6.3 Installation and basic settings


6.3.3 Running the Messaging client

To be able to operate the Messaging client, you must first log in by typing in your user name (domain name and user name) and password. If multiple clients are defined, you must also select a client from the drop-down list.

If you wish to speed up the login procedure, you can custom con-figure it (see below).

6.3.4 Basic settings

To select the basic Messaging client settings, select Options from the Tools menu.

If you check the Connect with network name box, you will no longer need to enter a user name and password at login, as the system will automatically log you in under the identity of the cur-rently logged-in workstation user. If there is more than one client defined on the system, you must select a client from the drop-down list.

In the Device Options dialogue you also can set the Automatic refresh every .. seconds interval, which defines the interval for refreshing the Alerts list on the client.

Fig. 3: Login

Fig. 4: Options





6.4.1 Screen layout

Fig. 5: Screen layout

Create a new messaging alert

Edit existing messaging alerts

Refreshes the existing messaging alert definitions if alert messaging is installed on multiple workstations and different alerts are set up on them.

Restarts a stopped messaging alert

Stops a running messaging alert

Deletes a messaging alert

Listed in the upper section of the messaging screen are the cur-rent alert definitions,

e.g., Checkpoint 1 – A, Checkpoint Alert, Automatic, Status: Stopped, Last Occurrence: 01.12.2004 11:36:15

6 Handshake.Logic – Messaging 6.4 User interface and program operation


The lower screen section shows triggered alerts,

e.g., Information: 15/12/2004 13:59:05, Alert "Checkpoint 1 - A" occurred: "The state of checkpoint "Checkpoint 1 - A" is now OK (restored after error); Details: Checkpoint on-line,"

as well as the corresponding actions taken in response,

e.g., Information: 15/12/2004 13:59:06, Action Executed: Record in Event Log, Message: "The state of checkpoint "Checkpoint 1 - A" is now OK (restored after error); Details: Checkpoint on-line."

Errors such as misconfigured SMS recipients are also listed here:

e.g., Error 15/12/2004 14:22:08, Error executing action ‘Send SMS (Nokia)/test’: "COM object with CLSID {99CE747A-AF04-4677-A393-FCB9670C1D35} is either invalid or not registered." Message: "Handshake Messaging test notification - please ig-nore."




6.4.2 Creating a new messaging alert

To define a new messaging alert you must first select its type:

Note: Once an alert definition has been created, the alert type can no longer be modified.

The following alert types are available for selection:

Checkpoint Alert – triggers if the status of a specific check-point changes (e.g. from on-line to off-line).

Counter Alert – triggers if the counter of a specific compo-nent on the premises reaches a certain value (e.g., '500 ad-missions to Section A')

Access Manager Alert – triggers if the status of the selected Access Manager changes (e.g. 'Access Manager service stopped').

Server Alert – triggers if the status of services on the server changes (e.g. 'Importer Service stopped').

Time Alert – allows for scheduled sending of messages (e.g., 'Time is 3:45pm; currently 1,298 persons on premises').

Depending on the selected alarm type, the following settings are required:

Fig. 6: Selecting an alert type



6.4.3 ‘General’ tab

This tab contains general details, including the name and type of the alert, and its Startup type.

If no alert name is specified, the name of the selected compo-nent is used by default.

Startup type may be set to:

Automatic – causes the system to begin monitoring the de-fined alert automatically;

Manual – requires monitoring of the defined alert to be started manually;

Disabled – deactivates the defined alert so that monitoring cannot be started manually or automatically.

Fig. 7: General alert settings




6.4.4 ‘Statistics’ tab

This tab contains relevant statistical details.

Last raised Last answered Occurred shows the number of executed alerts since setup of

the alert Since shows the setup date of the alert

Selecting the Reset statistics checkbox will reset the values once you hit the OK button.

Fig. 8: Statistical information



6.4.5 ‘Checkpoint / Access Manager / server’ tab

On this tab, you can select up to four different component status changes as alert triggers for the server, Access Manager, and checkpoint.

from (Any) to "Error" – this setting will trigger an alert in case of a component fault (e.g., ‘Checkpoint off-line,' 'Access Manager stopped,' 'Importer Service stopped,' etc.).

from "Error" to (Any) – triggers an alert if the operating status of a component changes from faulty to normal (e.g., 'Checkpoint on-line,' Access Manager started',' 'Importer service started,' etc.).

from "OK" to "Caution" – this setting triggers an alert in case the standard behaviour of the component is modified by means of a control card or via SKIDATA Monitor (e.g., change of operat-ing mode, change of light signals, change of operating mode us-ing a control card, etc.)

from "Caution" to "OK" – triggers an alert if the modified be-haviour of the system component is reset to normal by means of a control card or via SKIDATA Monitor (e.g., when resetting the device to standard behaviour by a synchronisation).

Fig. 9: Setting checkpoint / Ac-cess Manager / server status changes




6.4.6 ‘Counter’ tab

The counter alert will generate a notification message when the specified number of persons, gate passages, entries or exits is reached.

A separate Counter is available for each part of the event venue (entire venue, layout, section, access point, checkpoint, etc.).

Counter value (total) specifies the alert trigger value in terms of number of attending persons (entry transactions less exit trans-actions), number of gate passages (entry transactions plus exit transactions), or a fixed number of entries or exits.

The Direction specifies whether the alert should be triggered when the trigger count is reached with the previous count being lower (Ascending), or with the previous count being higher (De-scending).

Fig. 10: Counter alert settings



6.4.7 ‘Message’ tab

The alert message consists of plain text with system variables (placeholders) inserted as necessary. The alert messages are distributed in accordance with the selected response (e.g., by e-mail). If no message is specified, the program will send a stan-dard message.

Example of user-defined message: Time: 02.12.2004 09:43:53 – Checkpoint 1-A changed from OK to Error

Sample standard message: The status of checkpoint "Checkpoint 1-A" is now Error (pre-vious status: OK). Details: Checkpoint off-line"

The following placeholders may be used in the message (avail-ability depends on the alert type):

Date and time – inserts the current date and time when the alarm was triggered: e.g., %timestamp% = 03/12/2004 08:36:31

Date : shows the date when the alert was triggered: e.g., %date% = 03/12/2004

Fig. 11: Defining a message for checkpoint / counter / Access Manager / server alert




Time: indicates the time when the alert was triggered e.g., %time% = 08:36:31

Status (e.g., Online, Offline): indicates the current status of the component

Previous status: indicates the pre-alert status of the compo-nent. e.g., %oldstate% = OK, Attention or Error

Details: indicates details about the change e.g., %details% = Checkpoint On-line, Importer Service: Ser-vice stopped, etc.

Checkpoint: identifies the name of the checkpoint that caused the alert. e.g., %checkpoint% = Checkpoint 1 - A

Access Manager: identifies the name of the Access Manager that caused the alert. e.g., %accessmanager% = AM Stadium

Server: identifies the name of the server that caused the alert e.g., %server% = HSHsrv

Value: indicates the registered count. e.g., %value% = 5000

Release Value: indicates the counter value specified as the trigger value for the alert e.g., %triggervalue% = 5000

Previous Value: indicates the counter value registered before the trigger value was reached e.g., %oldvalue% = 4999

Direction: indicates the direction (increase/decrease, i.e., up/down) in which the counter has changed %direction% = increased or decreased

Counter: identifies the counter that triggered the alert e.g., %counter% = Sector A

Unit: indicates the counting unit e.g., %unit% = Persons, Passages, Entries and Exits



When using a time-based alert, it is possible to schedule certain counter details for automatic sending (see 6.4.8 ‘Schedule’ tab ).

A separate Counter is available for each part of the event venue (entire venue, layout, section, access point, checkpoint, etc.).

The Measurement specifies the number of attending persons (entry transactions less exit transactions), number of gate pas-sages (entry transactions plus exit transactions), or a fixed num-ber of entries or exits that should be displayed.

Date and Time are available as placeholders.

Fig. 12: Message for time trig-gered alert




6.4.8 ‘Schedule’ tab

Time-based alerts are not triggered by status changes or counter readings; instead they are issued at a pre-scheduled time.

Depending on the selection, the alarm may be triggered once, daily, weekly or only on certain days.

Fig. 13: Schedule



Example: On two event days a message is to be sent every 15 minutes between 5 pm and 9 pm stating the current number of persons on the premises.

From November 1st to November 3rd, between 5pm and 7pm, a message will be sent to the recipient within an interval of 15 min-utes.

e.g., Information 01-11-2005 17:15:00 Action executed: View in Handshake Monitor/Handshake Monitor. Message: "Sector A: 2951 Sector B: 3596 Sector C: 5896 Persons 01-11-2005 17:15:00"

Fig. 14: Sample schedule




6.4.9 'Response' tab

The response specifies the action to be taken if the alert is trig-gered.

The following response actions can be defined for the alert:

Execute command Record in eventlog Send text message Send E-Mail View SKIDATA Monitor

An alert may have several responses assigned to it. Once they are defined, the responses may be applied to different alert types. In that case, the alert to which the response refers to can be determined from the corresponding message.

Fig. 15: Response



6.4.9.1 Adding a response

To add a new response, hit the Add button and select a re-sponse type.

6.4.9.2 Action type ‘execute command’

To set up a new command type, select action type Run com-mand and hit the New button.

In the Name field you can enter a name for the new command action. The name will be shown in the ‘Recipient’ column of the Response list (see Fig. 15: Response).

The command line to be run consists of the Command itself, and optional or required Parameters. You may also use the place-holder %message% (representing the message body) as an ad-ditional parameter.

Important: The Run Command action should only be used by experienced Windows users.

Fig. 16: Add action

Fig. 17: Command action




If the alert is triggered, the corresponding command will be run automatically.

e.g. sent to a workstation on the network via ‘Netsend’ command.

6.4.9.3 Action type ‘record in eventlog’

The triggered alert causes an entry to be added to the Windows event log every time an action of type ‘Record in Eventlog’ is se-lected.

The log entry can be viewed with Windows Event Viewer under Application Log, source SDMGServer.

Fig. 18: Command action

Fig. 19: Record in event log



6.4.9.4 Action type ‘send text message’

SMS sending requires a Nokia cell phone connected to the server and the control software ‘Nokia PC Connectivity SDK 3.0’ or ‘Nokia PC Suite.’ This software is needed to send the mes-sages via textmessage.

When creating an action for sending a message via SMS, it is necessary to specify the Name and telephone Number of the re-cipient.

Fig. 20: Event Log record

Fig. 21: SMS receiver




Once you have created the action, you can configure it by click-ing the Configure button. The selection depends on the mobile phone model used.

6.4.9.5 Action type ‘send e-mail’

Creating the ‘Send E-Mail’ action allows you to generate an e-mail message for a specific recipient via an SMTP server.

The Name and E-mail address specify the message recipient.

Once you have created the action, you can configure it by click-ing the Configure button.

This requires input of an SMTP Server name. The Sender ad-dress must be a valid e-mail address.

Fig. 22: Mobile phone selection

Fig. 23: E-mail receiver

Fig. 24: E-mail configuration



Note: Ensure proper spelling of the e-mail address to avoid errors.

Fig. 25: E- mail received

6.4.9.6 Action type "view in Monitor"

Alert messages can be displayed in the SKIDATA Monitor.

If the defined alert is triggered, the SKIDATA Monitor will indicate a system event.

Fig. 26: View in SKIDATA Moni-tor




Fig. 27: View alert in SKIDATA Monitor

6.4.9.7 Editing a response

To edit a previously defined and mapped response, click on Add and select an Actiontype.

This will bring up a list of defined responses for the selected ac-tiontype. You can edit and adjust various Properties depending on the type of action you have selected.

Fig. 28: Edit response



To edit the basic settings of the action type, click Configure.

6.4.9.8 Testing a response

To test your response settings, simply hit the Test button. A mes-sage will be displayed, indicating whether or not the defined ac-tion could be completed successfully.

This will cause the message to be sent to the recipient, e.g. in the form of an e-mail: Handshake Messaging test notification - please ignore.

Fig. 29: Testing an action

Handshake.Logic – Archive 7

7 Archive

Version 3.0 / 1.0 18 pages Copyright 2006 by SKIDATA AG

7 Handshake.Logic – Archive 7.1 Contents


7.1 Contents

7.1 Contents 2

7.2 Archive 3

7.3 Installation 4 7.3.1 Assigning user rights 4 7.3.2 Running the Archive 5 7.3.3 Basic settings 5

7.4 User interface and program operation 6 7.4.1 Database backup 7 7.4.2 Purging the database 9 7.4.2.1 Purging event data 10 7.4.2.2 Purging based on ticket identification 11 7.4.2.3 Whitelist selection 12 7.4.2.4 Blacklists 13 7.4.2.5 Import versions 13 7.4.2.6 Archive 13 7.4.2.7 System journal entries 13 7.4.3 Creating an archive 15 7.4.4 Archive mode 17


Archive 7.2


7.2 Archive

The Archive is used for extracting and deleting expired or obsolete transaction and configuration data from the online database. The data backup and archiving functions of the Archive are designed to optimise system performance and speed.

When restoring an archive backup of a database, the database format is automatically adapted to the latest Handshake.Logic version and made available in the form of a separate read-only database. When logging into the handshake™ Explorer the user may choose which database to view: the online database or the one restored from the archive.

This allows for bringing up action details that were previously deleted. In addition, previous reports can be reprinted as needed.

7 Handshake.Logic – Archive 7.3 Installation


7.3 Installation

The Archive module is installed automatically at the server when the handshake™ server setup is executed.

Important: The Archive can only be installed and run on the server.

Once the Server Setup is completed, an icon with a link to the Archive will be placed in the start menu.

7.3.1 Assigning user rights

To be able to launch the Archive, the logged-in user must have a user right. User rights can be assigned as needed via handshake™ Explorer.

The 'Archive Manager' right gives the user unrestricted archiving privileges with access to all options.

The "Archive User" right entitles the user to browse the archive database, generate reports from archived data, etc.

Fig. 1: User right administration


Installation 7.3


7.3.2 Running the Archive

To be able to operate the Archive, you must first log in by typing in your user name (domain name and user name) and password. If multiple clients are defined, you must also select a client from the drop-down list.

If you wish to speed up the login procedure, you can custom configure it (see below).

7.3.3 Basic settings You may modify the login settings for Archive via Options on the Tools menu.

If you check the Connect with network name box, you will no longer need to enter a user name and password at login, as the system will automatically log you in under the identity of the currently logged-in workstation user. If there is more than one client defined on the system, you must select a client from the drop-down list.

Fig. 2: Login

Fig. 3: System settings

7 Handshake.Logic – Archive 7.4 User interface and program operation



The Archive provides three main functions:

Save – creates a database backup in the form of an SQL Enterprise Manager database backup file;

Clear – performs a database cleanup by purging the online database from expired or obsolete transaction and configuration data; and

Create – restores a database from an archive file; the resulting database is automatically adapted to the latest Handshake.Logic version and provided as a separate read-only database for free viewing.

Fig. 4: Database archiving




7.4.1 Database backup

The Save command creates a full backup of the current data. This backup is equivalent to the database backup created by SQL Enterprise Manager.

Clicking the Save button in the Functions dialogue will let you configure and start the archiving procedure.

The Name and Description boxes may be filled in as needed.

Target specifies the path and file name for the backup. After using the backup feature for the first time, the file of the last backup will be suggested by default.

If no new file path and name are entered here, the backup will be appended to the most recent backup file.

If you wish to save the backup to a new file, simply type a new file path and name.

When you are done, hit the OK button to start the backup.

When archiving data, a blue indicator bar will be displayed to show the progress of the procedure. When the backup is complete, an information pop-up window will be displayed.

Fig. 5: Database backup



A system journal entry will be generated when the backup procedure completes.

Fig. 6: Backup information - progress bar

Fig. 7: System journal entry




7.4.2 Purging the database

Database purging allows users to delete expired or obsolete transaction and configuration entries from the database.

Important: Always backup the database before running the purging routine.

Note that purged entries will no longer be available for reports generated from the online database.

Backups are therefore necessary to access purged entries later on. The required data are retrieved and stored in the archive database for read-only viewing (see 7.4.4 Archive mode).

Depending on the configuration and use of Handshake.Logic, purging may be applied to event data (in case of an event-based configuration) or ticket properties and data ranges (in case of a date-based configuration.

Fig. 8: Record selection for database purging



7.4.2.1 Purging event data

If Handshake.Logic is used primarily on a per-event basis, the easiest way to purge the database is to delete the transaction records of an entire event at a time (instead of each record individually). To be able to do so, the following conditions must be met:

The event must be defined (see Chapter 3 of handshake™ Explorer)

there must be existing transaction records (access records) for this event.

Clicking on the Clear button in the main Archive dialogue will open a data window where you can select the data to be removed from the database. Click the Select button in the upper section (Events). This will bring up the dialogue showing a list of event records containing access data.

Select the Events to be Deleted; this will bring up the list of ticket identification for which access data records exist.

When selecting an event, all displayed ticket identification will be covered (i.e. activated by default). To prevent certain ticket properties from being deleted, simply clear the corresponding checkbox.

Fig. 9: Event selection dialogue




Note: Statistics will only be deleted if they are not mapped to valid permissions.

Per-event database purging means the deletion of all tickets of the specified event that were registered at the checkpoint. Tickets with properties that were deselected in the selection dialogue will not be purged from the database. The program will automatically identify all permission records of matching tickets for the selected event. Permissions still valid for other events will not be purged. All statistics and blacklist and whitelist entries of matching ticket permissions will be purged from the database (i.e., deleted).

7.4.2.2 Purging based on ticket identification

If Handshake.Logic is used primarily on a date basis (annual events), the best way to purge the database is by specifying a certain period and ticket identification (rather than individual permissions). To be able to do so, the following conditions must be met:

the time period must be specified, transaction records (access data) must exist for this period.

Clicking on the Clear button in the main Archive dialogue will open a data window where you can select the data to be removed from the database. Specify the period for which you wish to delete the access data of specific ticket identification; when you are done, click the Select button. This will bring up a window where you can view and select all ticket identification used for transactions during the specified period.

Fig. 10: Ticket properties



Select the ticket identification to be deleted by clicking on it. This will purge all transactions of the selected ticket identification that have been used for transactions during the specified period.

The option Transactions without ticket identification is selected by default. Transactions recorded within the specified period but not linked to any ticket identification will also be deleted (e.g., transactions that were caused by irregularities).

Confirm your selection by hitting the OK button.

Note: Statistics will only be deleted if they are not linked to valid permissions.

7.4.2.3 Whitelist selection

It is possible to delete whitelist records recorded within a specific custom-definable period. This will remove all whitelist entries whose expiry date falls within the selected period (from – until dates), provided they are not linked to current records.

To delete whitelist entries that do not have an expiry date, click the "Select..." button and activate the Entries without Expiry Date checkbox".

Fig. 11: Whitelist selection




7.4.2.4 Blacklists

It is possible to delete blacklist entries recorded within a specific custom-definable period. This purges the database from all blacklist entries and data carrier and permission blocks whose 'blocked from'/'blocked until' dates fall within the selected period.

To purge the database from blacklist entries, enter the from and until dates.

7.4.2.5 Import versions

The handshake™ Importer automatically imports ticket properties from the ticket system. The import details are stored in the database (see Explorer Chapter 3 – 3.6.9 Imports).

To delete the existing import data, enter the from and until dates.

7.4.2.6 Archive

When creating an archive database, relevant information about the storage location, version, etc. are written to a table. These details may be deleted based on the specification of a period.

To purge the database from archive information entries, enter the from and until dates. The until date must be no later than one month prior to the current date.

7.4.2.7 System journal entries

To delete existing journal entries, specify a period (from and until dates). The until date must be no later than one month prior to the current date. When your selection is complete, hit the OK button to start purging. The selected data will be removed step by step from the database. In case of an error, the procedure will abort, and the database will be rolled back to the status before the last step.



A separate journal entry will be created for every step of the purging procedure.

Fig. 12: Database purging successfully completed

Fig. 13: Database purging – journal entries




7.4.3 Creating an archive

The "Create Archive" function allows you to restore a previously saved database. The function is equivalent to the "Restore Database" function of SQL Manager.

Calling the "Create Archive" function will restore the archived records and write them to a read-only archive database. If necessary, the format will be adjusted to the latest Handshake.Logic version.

Clicking the Create button in the main Archive window will bring up the data archive dialogue.

In case there is no archive database available yet, one must be created. To do so, enter a Database name and Journal Database, as well as a New User and User Password. Confirm your entries and click the OK button to create the initial database file.

Important: Only the database administrator is permitted to create archive files.

Fig. 14: Creating an archive database file



If an archive database already exists, all previous data backups are listed on the Archive dropdown list.

Select a backup from the list and confirm your choice by hitting the OK button. The selected backup will be restored into the archive database for read-only viewing. The restoration process will overwrite any previous contents of the archive database.

Important: Only the database administrator is permitted to restore data into the archive database.

When archiving data, a blue indicator bar will be displayed to show the progress of the procedure. When the backup is complete, an information pop-up window will be displayed.

Fig. 15: Create archive

Fig. 16: Create archive




7.4.4 Archive mode

To be able to browse the archive database, the logged-on user must have the appropriate access privileges (see 7.3.1 Assigning user ).

Once an archive database has been created, users may specify in handshake™ Explorer whether they want to work with the online database or the archive database.

To activate Archive mode, click the button. If more than one client is available, one must be selected. This will activate Archive mode.

With Archive mode activated, it is possible to create reports and view configuration settings. However, nothing may be modified, deleted, or created, which is why the control buttons for these actions are disabled.

To terminate Archive mode, click the control button to return to online mode. If more than one client is available, one must be selected.

Fig. 17: Archive mode



Handshake.Logic – Technical Terms 8

8 Technical Terms


8 Handshake.Logic – Technical Terms 8.1 Contents


8.1 Contents

8.1 Contents 2 8.1.1 A 3 8.1.2 B 3 8.1.3 C 3 8.1.4 D 5 8.1.5 E 5 8.1.6 F 6 8.1.7 G 6 8.1.8 H 7 8.1.9 I 7 8.1.10 L 7 8.1.11 M 7 8.1.12 N 8 8.1.13 O 8 8.1.14 P 8 8.1.15 R 9 8.1.16 S 10 8.1.17 T 10 8.1.18 U 10 8.1.19 V 10 8.1.20 W 10 8.1.21 X 10


Contents 8.1


8.1.1 A

Access Manager The Access Manager includes all processes required to evaluate the tickets and control the access terminals.

Actions Actions define the behaviour of checkpoints with respect to as-signed Ticket properties. Actions will only be triggered if ticket verification is positive.

Archive The Archive is used for extracting and deleting expired or obso-lete transaction and configuration data from the online database. The data backup and archiving functions of the Archive are de-signed to optimise system performance and speed.

Area An area can be accessed and/or left through one or more gates. The area is the smallest part of a venue access control can be applied to.

8.1.2 B

Blacklist The blacklist contains information about blocked tickets. This information is automatically adopted by the importer or added manually to the Handshake.Logic system so these tickets can be rejected at the checkpoints.

8.1.3 C

Checks Check in the form of a permit, condition, restriction, denial, valid-ity check, or control function. A ticket will be accepted at a check-point if a permission type and at least a positive check exists for the properties of this ticket.

Check Engine The check engine is the process behind the access manager, and is responsible for the ticket control.

Checkpoint A checkpoint consists of a device for ticket control (e.g. turnstile with ticket reader, Handheld). The central task of a checkpoint is to check and verify electronically readable tickets, grant access if the ticket is valid or refuse admission if it is not.

CDF - Code Definition File The Code Definition File contains all required information for in-terpreting the information electronically stored in the ticket in the Handshake.Logic system.

Airmiles = airmiles.cdf SKIDATA™ APT450 Tickets = apt450.cdf Billetlugen DK = billetlugen CIEC Beijing = ciec.cdf Computer Software = computersoft.cdf CTS Eventim = ctseventim.cdf



Datasystems Tickets = datasystems.cdf Dehaan Tickets = dehaan.cdf DMR Tickets = dmr.cdf EM 2004 Portugal = em2004.cdf ESP Ticketing = esp.cdf Euro Ticket = euroticket.cdf Fingo Munich = fingo.cdf Fair Lisbon = fairlisbon.cdf G7 Tickets = g7.cdf Gateway Ticketting Systems = gateway.cdf Fortworth Gateway Tickets = fortworth_gw.cdf Galathea STS = galathea.cdf Generic Efteling Tickets = genefteling.cdf Generic Tickets = generic.cdf GOB Tickets = gob.cdf IFEMA Madrid Tickets = ifema.cdf Kart Tickets = kart.cdf Cologne Tickets = koeln.cdf LogicaCMG = logicacmg.cdf Lottomatica Italien = lottomatica.cdf Mircroflex = microflex.cdf Netimage = netimage.cdf Octal Tickets = octal.cdf Ö-Ticket Austria= oticket.cdf PKE Innsbruck = pketicket.cdf Quatro = quatro.cdf Sazka Arena = sazka.cdf SKIDATA™ Control Tickets = sdControl.cdf SKIDATA™ Tickets = skidata.cdf Senix = senix.cdf Siemens/EWO Soft = siemens.cdf Siport = siport.cdf Sistic Singapor = sistic.cdf Synchro Tickets = synchro.cdf Smartmachine Mobile Tickets = smartmachine.cdf SKIDATA Car Access SPT 400 = spt400.cdf Starparks Europe = freedom.cdf Tessitura = tessitura.cdf Ticket Online = ticketOnline.cdf Tickets.com US = advantix Ticketsdotcom = ticketscom.cdf TicketSoft = ticketsoft.cdf Ticketsoft 2D Tickets = ticketsoft_2d.cdf Ticketweb = ticketweb.cdf Ticnet Tickets = ticnet.cdf to 10 = to10.cdf Tourbizz = tourbizz.cdf T-Systems Germany = tsystems.cdf UCP Tickets = ucpicket.cdf


Contents 8.1


Visionone = visionone.cdf Vodafone = vodafone.cdf Hospitality WM 2006 = wm2006hospitality.cdf

Condition Introduces extended permissions for a ticket in addition to the permit. Conditions represent additional permissions.

Control Function The control function is used to modify the behaviour of reader or turnstile with the use of a ticket directly at the checkpoint

8.1.4 D

Data medium blocks When a data medium block is enforced, the entire data carrier as such is blocked, which means it is no longer valid for existing e-vent.

Denial This parameter specifies a ticket property that is checked for at checkpoints during a specific time period and does not entitle the ticket holder to admission.

Domain A group of networked computers that share a common communi-cations address.

Double-use waiting period Defines the time period (in minutes) to block the turnstile between an entry and a re-entry (or exit and re-exit) without a valid exit (entry) mark on the ticket. After the set double usage time, the ticket can enter (exit) without a valid exit – Anti Pass Back time.

8.1.5 E

Event Manager User right for administration of events, setting up permissions and conditions.

Event Location Manager User right for Administration of event venue profiles, access con-trol units, access permissions and actions.

Exporter The Exporter is an own service looking for defined exports set up within the handshake™ Explorer.

Extended Checks Extended checks offer the possibility of attaching an additional entry check done with a biometric scanner (Bioscan), resp. doing a two step validation using the Handheld Soft Pinpad to overrule the decision of the checkpoint.

Extension Box „mobile Ticketing“ The Extension Box for the Fit All Compact reader provides sup-port for several innovative access technologies in addition to the



‘classic’ barcode and contact less technologies. The Compact reader now also supports 2-D barcodes. As used, for example, in mobile ticketing’ via mobile phone. The device is intended to be used exclusively in combination with the Compact reader;

Extension Box „Print@home“ AS x70i C / EB - PAH The Extension Box for the Fit All Compact reader has been de-signed specifically for reading ‘print@home’ type tickets. The de-vice is intended to be used exclusively in combination with the Compact reader; it cannot function as a standalone reader. The integrated barcode scanner supports reading of barcodes in 1-D, PDF417, and 2-D formats, providing a maximum scanning area of 8x10 cm.

8.1.6 F

File Format File Format, Version and Transmission type parameters must be specified in accordance with the respective details agreed with the ticketing system partner.

FTP stands for File Transfer Protocol. A protocol is a language that enables computers to speak to one another.

8.1.7 G

Gate A gate is a group of checkpoints. Gates are assigned to an area.

Generic File based for automatic file transfer via File System or FTP.

Global The global property can be used within the configuration of an-other client. The other client can use the property for his access configuration but cannot change or delete the property.

Fig. 1: File Format and Transmis-sion types


Contents 8.1


8.1.8 H

Handheld Terminal The Handheld Terminal AS x70i HH supports reading of tickets with visible barcodes and contactless data mediums. The termi-nal is integrated into the system network via the Wireless LAN (WLAN). Using the PPT2800 and Keycore module 125 kHz (Key-card, Wristbands) and 13 MHz can be scanned. Using the PPT8800 and RFID Module 125 kHz (Keycard, Wristbands), 13 MHz, ISO 15693 (Keycard ISO, Keycard ISO DUAL, Infineon), ISO 14443 (Mifare) can be read.

8.1.9 I

Interface The Ticket systems can transfer data to the Handshake.Logic system in various formats, depending on the capability of the ticket system. The necessary data are transferred to Hand-shake.Logic by way of the Importer.

ISO 14443 Starting with Handshake.Logic Version 2.98 following Mifare data mediums are supported: Mifare classic, Mifare Ultralight and My-d. The checkpoint types AS x70i CF/V2, OBID-classic-pro and the Handheld AS x70i HH88/WLAN with RFID module are able to read ISO 14443 data mediums.

8.1.10 L

Layout A layout groups one or more areas into a logical access concept. Layouts are designed to allow for hardware to be used in different configurations.

Link A segment of text or a graphical item that serves as a cross-reference between parts of a hypertext document or between fi-les or hypertext documents. Also called hotlink, hyperlink.

8.1.11 M

Messaging With the Messaging client operators have a tool allowing to be informed about events on the access control side. Without having to actively run reports or perform investigations, messages from the Handshake.Logic system are automatically sent to the regis-tered user (e.g. administrator).

Mifare Classic Consists of 16 sectors each with 4 Blocks, to enable the reading of the block data; a level key must be defined.

Mifare Ultralight Does not need a level key and supports text data.

My-d Supports simple and secure mode, Handshake.Logic uses the simple mode.



Monitor The SKIDATA Monitor is a special Windows-based application that can be installed and run independent of other Hand-shake.Logic components. The SKIDATA Monitor has a passive and an active function: monitoring the entire system (passive) and performing various system tasks (active).

Monitor: System Monitoring Running the SKIDATA Monitor (passive right) and using the Messaging client.

Monitor: System Monitoring and Control Running the SKIDATA Monitor and executing system control functions (e.g., manual turnstile release – i.e., active right).

8.1.12 N

Nessie Nessie is the standard interface by Ticketcorner for Ticketsoft and KART compliant Tickets. Note that Nessie can only be used with Ticketsoft and KART tickets and requires a socket connec-tion.

8.1.13 O

Orientation The gate direction is configured for normal passage direction by default. By reverting the reader orientation, a gate can be con-verted from an access gate to an exit gate (and vice versa). An important parameter dependent on the reader orientation is the turnstile direction.

8.1.14 P

Partner service User right with special access privileges; reserved for SKIDATA sales and service partners.

Partner Manager User right for administration of ticket systems, ticket properties and imports.

Fig. 2: Gate direction


Contents 8.1


Permission types Permission types determine the basic value behaviour of tickets within a specific period. Each verified ticket is assigned the basic value behaviour based on the permission types defined in this dialogue.

Permission blocks A permission block allows you to block (i.e., invalidate) the single permission on the data medium, so it is blocked only for a spe-cific event while leaving it valid for all others.

Permit Every ticket being verified must have at least one applicable permit (otherwise it will be rejected).

8.1.15 R

RF Technology The checkpoints used for Handshake.Logic supports the follow-ing RF technologies.

Report Manager Permission to use the Reporter and to create the admission sta-tistics (Admission statistics, Visitor frequency analysis, length of stay).

Restriction Imposes a constraint on the possible use of a data carrier or the permission to access certain areas, events or the entire premises (e.g., the maximum number of allowed re-entries).

Right User rights are assigned in accordance with operators responsi-bilities.

Fig. 3: RF Technology



8.1.16 S

SQL Short for "Structured Query Language"

8.1.17 T

TCP/IP Transmission Control Protocol over Internet Protocol.

Ticket Types Barcode and RF (contactless) data medium can be used in Handshake.Logic. Which barcode and RF verification method is used, is a definition made by the ticketing partner.

8.1.18 U

User Manager User right for the administration of user records.

8.1.19 V

Validity Check A validity check provides an additional way of checking a ticket; this requires a ticket system with whitelist support and a working XML interface connection.

Venue The venue is the representation of the external characteristics. More than one venue can be administered. Tickets of visitors proceeding from one venue to the other are not checked.

8.1.20 W

Waiting Period Defines the time period (in minutes) where an entry / exit is not allowed since the last entry / exit even a valid exit / entry mark is on the ticket. The waiting period can be set in entry or exit direc-tion.

Whitelist The whitelist contains Information about tickets sold. This infor-mation is automatically adopted by the importer to the Hand-shake.Logic system so these tickets can be granted access at the checkpoints.

8.1.21 X

XML The XML (Extended Mark-up Language) interface is intended for file-based data exchange by file system, FTP or socket connec-tion. XML is the standard interface for new ticketing partners. File transfer is performed in XML format (industry standard).

Empty Pages 9

9 Empty Pages

10 Pages Copyright 2006 by SKIDATA AG

9 Empty Pages

Page 2 © SKIDATA AG

Empty Pages 9

© SKIDATA AG Page 3

9 Empty Pages


Empty Pages 9


9 Empty Pages


Empty Pages 9


9 Empty Pages


Empty Pages 9


9 Empty Pages


Documents

Handshake V3.0 1 0 en Man