Procedure for System Take-Overs

C. DATA GATHERING

• Physical Database 
• People Database

D. PHYSICAL DATABASE CONSTRUCTION

• Task 1: BluBØX system design
• Task 2: Gather more detailed data about the current system’s configuration
• Task 3: Completion of the detailed data entry workbook
• Task 4: Transcription of the information into BluSKY

E. PEOPLE DATABASE CONSTRUCTION

F. PRE-REQUISITES FOR PEOPLE IMPORTATION

• Readers (in the physical databases)
• Floors (in the physical databases)
• Schedules 
• Access Levels or Access Groups  
• Roles
• Photos
• Occupancies 
• Cards & Barcodes
• Card Types (Formats)

G. UNDERSTANDING THE PERSONNEL IMPORT FUNCTION

•  The BluB0X “People Data” Worksheet (PDW) 
• The PDW does not import…
• The maximum number of people in a PDW is approximately 600

H. STEPS NEEDED TO PREPARE THE PDWs

• Eliminate Duplicate People Records
• Identify Assigned Access Levels
• Identify Roles
• Identify ADA Flags

I. THE (OPTIONAL) PEOPLE DATA PREP WORKSHEET

J. CREATING RULES FOR THE SYSTEM

• Basic Rules
  • Access Control 
  • Alarm and intrusion  
  • Power analytics 
  • Video Surveillance
• Rule Creation Guidelines

A. GENERAL

This document describes the steps that are needed to complete a BluSKY database when taking-over an existing security system. 

No two systems are fully the same, so the process of collecting the required data is usually different from one system to the other: it is up to the Reseller to determine the best way of obtaining the required data.

• BluBØX makes available several documents to assist with the System Take Over (STO) process. They can be used at will. They can be found in a Dropbox file at: https://bit.ly/2SedNm1  or in BluINFO at:

THE STO DOCUMENTS ARE AS FOLLOWS:

• STO – Check List is a short list of the items needing attention in preparation for Take-Over 
  Click to view EXCEL file: 05 STO - Check List.xlsx
   
• STO – Procedure is this document – a more detailed description of the procedure 
  Click to view WORD file: 10 STO - Procedure.docx
   
• STO – Initial Hardware Data Collection can be useful during system walk-throughs to gather data that will be needed to generate more comprehensive system hardware data. Click to view EXCEL file: 20 STO - Initial Hardware Data Collection.xlsx
   
• STO – Physical Data Prep is the worksheet that lays out the detailed data that must be entered in BluSKY
  Click to view EXCEL file:  22 STO - Physical Data Prep.xlsx Click to view EXCEL file: 25 STO - Physical Data Prep - Sample.xlsx
   

It has been found to be easier to layout the data in this format before entering it into BluSKY as opposed to attempting to enter it directly
 

• STO – Occupancy List is the worksheet that can be used to identify all the Occupancies in the Facility and the Administrator information if needed. Click to view EXCEL file: 30 Occupancy List.xlsx Click to view EXCEL file: 32 Occupancy List - Sample.xlsx
   
• STO – People Data Prep is the worksheet that can be used to organize the Occupant (People) data for importation into BluSKY.
  Click to view EXCEL file: 40 STO - People Data Prep.xlsx Click to view EXCEL file: 45 STO - People Data Prep - Sample.xlsx

This worksheet helps with several required personnel record manipulations before importation can start.

B. INITIAL FAMILIARIZATION (SYSTEM WALK-THROUGH)

The first step is to make a full assessment of the functionality of the existing System being taken-over - on walk through, answer the following questions:.

• Type of Facility:
  • Single Occupancy / Multi-Occupancy / Other
     
• Current Database Management Procedure:
  • Central - Property Office manages for all Occupancies
  • Distributed - Each Occupancy manages its own database
     
• Visitor / Vendor Management
  • Brand of the system in use
  • Visitor reception method in the Lobby
    • # of Stations
    • Visitor self-registration kiosk(s)?
  • Control of vendors at the dock
  • Are visitors pre-registered?
  • Do they receive credentials?
  • Can the credentials be valid for more than one day?
  • Do the credentials give access or are visitors always escorted?
  • Are photos taken?  Printed on badges?
  • Click to view EXCEL file: 50 Vendor MgmtData Capture.xlsx
• Video Surveillance 
  Click to view EXCEL file: 60 Camera Configuration - Sample.xlsx
  • Brand
  • Cameras
    • Number of Cameras
    • Camera types: Analog / IP / Resolution / Frames-per-sec / Motion recording / PTZ
  • Any integration between the video and the access system?
  • Analytics?
     
• Monitoring Function
  • Is Access monitored?  Where from?
  • Is there Remote control of security points (portals, floors, alarm devices).  Where from?
  • Is there Video monitoring.  Where from?
  • Are Alarms monitored?  Where from?
     
• Client (Administrative) Stations
  • Age and characteristics of each PC (brand of PC, OS, Memory)
  • For the issuance of credentials
  • For reviewing video
  • For reporting
  • Other
     
• Communications Network Infrastructure
  • Internet connectivity and Bandwidth
  • Network Layout
    • Dedicated to Security / Shared with Business
    • Isolation from the business network
    • Do users currently have remote access to the video and/or access system?
       
• Credential Types
  • For Occupants:
    • Prox / iClass / Barcodes / Fingerprint / Other biometric
  • For Visitors:
    • Paper badges / Prox cards / Barcodes / Fingerprint / Other biometric
  • For Vendors:
    • Paper badges / Prox cards / Barcodes / Fingerprint / Other biometric
       
• Cards/Barcodes
  • Sequences in use
  • Card Types
    • How many types?
    • What types: 26 bit / 37 bit / other / with or without facility code?
       
• Photos
  • Used for Occupants / Visitors / Vendors?
  • Printed on the credentials?
     
• Badge Templates in use
  • How many designs?
  • For Occupants / For Visitors / For Vendors
     
• Portal Readers
  • Turnstiles 
    • Number of lanes 
    • Are there OUT Readers?
    • More than one type reader at each end of the lanes?
      • What types?
    • Turnstile Reader controller location
      • Inside the Turnstile Bollards?
      • Remote Location?
         
  • Doors
    • Number of Doors 
    • Are there OUT Readers?
    • More than one type of reader at each Door?
      • What types?
    • Special Equipment such as RX, MD, Key Override, Door Opener
    • Door reader controller location
      • At the door?
      • Remote location?
         
  • Gates
    • Number of Gates 
    • Readers / Keypads on either side?
    • More than one type of reader at each Gate?
      • What types?
    • Special Equipment such as RX, MD, Loop
    • Gate Reader controller location
      • At the Door?
      • Remote Location?
         
• Elevators
  • # of Banks (Include Freights and Shuttles)
    • Floors served by Bank
  • Elevator System Type
    • Destination Dispatch 
      • What Elevator Company
      • How many DDE Kiosks
  • Relay-controlled
    • Readers are inside the elevators 
  • Readers control the lobby-call buttons only
     
• Other Devices
  • Intercom Stations
    • Brand name
    • Type:  Analog / Digital / IP
    • / Audio Only / Video
    • # of Calling Stations 
      • Locations
    • # of Master Stations 
      • Locations
• / Alarms / Other
  • Number of Points
  • Type: Door Contact or Motion (no associated reader), Glass break, Other
  • Special triggers

C. DATA GATHERING

• Two Separate tasks:
  • Physical Database. That’s the creation of the records in BluSKY that define all the elements of the security system such as controllers, readers, doors, floors, alarm devices, cameras, etc…
  • People Database. That’s the creation of the records that define the organizational structure inside the property.

D. PHYSICAL DATABASE CONSTRUCTION

• Task 1: BluBØX system design. Consists of planning the Mercury-based implementation of the BluBØX replacement system.
  • See the proposed Sample Block Diagram: STO - 21 STO - Sample Mercury LSP Block Diagram.pdf
• Task 2: Initial Hardware Data Collection.  
  • BluBØX proposes the use of the document “STO – Hardware Data Collection” 20 STO - Initial Hardware Data Collection.xlsx
• Task 3: Completion of the Detailed Data Prep workbook 40 STO - People Data Prep.xlsx
•  It is easier to lay it all out in Excel and then transcribe into BluSKY.
  • BluBØX proposes the use of the document “STO – Physical Data” Workbook  22 STO - Physical Data Prep.xlsx
  • Reference the populated “STO – Physical Data – Sample” Workbook 25 STO - Physical Data Prep - Sample.xlsx
• Task 4: Transcription of the information from the “STO – Physical Data” Workbook into BluSKY 22 STO - Physical Data Prep.xlsx

E. PEOPLE DATABASE CONSTRUCTION

Tips

• Unlike most systems, BluSKY puts significant emphasis on Occupancies (i.e. the organizations to which people belong.)
  • No person record can be created unless it is assigned to a defined Occupancy – so a list of Occupancies must be defined first.
• Things to know about each Occupancy:
  • Exact name / Floors occupied / Reception floor(s) / Mailroom floor(s) / Main telephone #. 
• If database administration is decentralized, for each Occupancy:
  • Name/e-mail address/telephone number of the principal Database Administrator

F. PRE-REQUISITE FOR PEOPLE IMPORTATION

The elements that must be defined in BluSKY before processing the people for importation are as follows:

• Readers (in the physical databases)
• Floors (in the physical databases)
• Schedules 
  • These are the Access Schedules – Access schedules govern when a credential will be granted access at a security point. (There are also Device Schedules that govern things such as when a door shall be locked or unlocked – These are not needed for these purposes).  
• Access Levels or Access Groups. See the section on Access Rights, Levels and Groups for important information before creating these items.
  • Readers and Schedules must have been defined before Access Levels can be defined.
• Roles govern what people can do when they log-into BluSKY. 
  • In some cases, only a few people are authorized to log-into BluSKY - in which case roles can be defined later and applied manually after the importation, 
  • But some roles may be more widespread – such as the Visitor Invitation role which may be given by default to all Occupants of the Facility.  Best do that at the time of importation to avoid the need for later manual intervention.
• Photos
  • If photos are to be transferred to BluSKY, a Photos folder must be created that contains all the photos in a popular format such as .jpeg, .bmp, or .tiff.  
  • This folder must be sent to BluBØX to be uploaded into Azure where it serves as the source of photos during importation.  

Occupancies  

• Required information: Name of each Occupancy / Floors occupied / Principal (default) floor. 
• Desirable: List of floors that have a Reception desk / Floors with a Mail Room / the general phone number for the Occupancy / the phone number for the mailroom(s).  
• Administrator Information: In the event the administration of the databases is (or will be) distributed, at least one Administrator name and e-mail address must be provided for each Occupancy.  (See proposed Occupancy List worksheet).
• Cards & Barcodes
  • Determine
    • Formats in use.
    • Sequences in use.

DEALING WITH CARDS

• LIMITATION: The Mercury panels can hold only sixteen (16) card types (also called “formats”).
• Identify ALL card formats that are in use at the property, all the card sequences of each format, along with their Facility Code.
• Also request a list of all cards that are waiting to be issued.  One of the easier ways of getting that information is to request photos of the labels of the boxes that contain the un-issued cards.
• Add those card #s to the list of issued card #s, then sort by card #.
• Identify significant gaps in the listed card # sequences: they are indicative of the possible end of one sequence and the start of a new sequence.
• Determine the card type for every identified sequence: pick-out the bit length (commonly 26 bit, 32 bit, 37 bit, 48 bit), the card # field, and the facility code field (if any).  The remaining bits are usually parity information.
  • Bear in mind that many systems, including the Mercury controllers, do not consider the facility code: this results in occasional duplicate card #s, and that can create havoc in the system.
• At the end of the analysis, you should have identified the number of card types that are in use.  
• Determine whether the number of card types is higher or close to the maximum 16 allowed:  If so, find a way of combining several card types into one to give the client room for expansion.
  • There are many ways of doing this: for instance, several standard 26-bit card formats can be combined into just one card type by registering the external card #s as the concatenation of the Facility Code and the Card # and setting the card type as 26 bit / No Facility Code. 
  • Based on recent experience, BluB0X now highly recommends following the “Alternate Card Number” strategy when setting up multi-facility or multi-occupancy environments.  See the article on “Alternate Card Formats”.
  • Consult BluBØX Professional Services if you need help with this very important process.
•  Upload all the card sequences to BluSKY using “Card Uploads” under “Set-Up/System Set-Up” in BluSKY.

H. STEPS NEEDED TO PREPARE THE PDWs

• Eliminate Duplicate People Records
  • Most security system architectures feature one record for each card #.  Accordingly, the First/Last Name of people who have been assigned several card #s will appear several times.  BluSKY’s architecture allows only one record for each person, but that record is capable of holding multiple card #s.  So all the records in the source database that are duplicate First / Last Name combinations must be identified, removed from the PDWs, but saved so the additional card #s can be added after the importation to each person’s BluSKY record.
• Identify Assigned Access Levels
  • Access Levels that are flagged in BluSKY as “default” for a particular Occupancy are automatically assigned to people during importation of that Occupancy’s PDW.  However, some people may have Access Levels other than the default(s) that are common to all, so after importation, you must manually edit those people’s records.  This can be done using BluSKY’s global functions, but it can be time-consuming to select a large number of people records before executing the global function.  
  • It is often faster to judiciously sort the list of people by Access Level before importing, and cut the Occupancy’s PDW into several PDWs, each holding the people who receive a certain set of Access Levels.  Then before each PDW import, set the default access levels in BluSKY to match the Levels in the PDW being imported.  
  • Be sure to restore the proper definitive default Access Levels for the Occupancy when done with importing.
• Identify Roles
  • A Role is a list of permissions that a person might have once logged into BluSKY.
  • Roles that are flagged in BluSKY as “default” for a particular Occupancy are automatically assigned to people during importation of that Occupancy’s PDW.  It may, therefore, be a good idea to set an Occupancy’s Default Roles in BluSKY before importing.  If this is not done, Roles will have to be assigned manually after importation.  BluSKY does have a global function for Roles as it does for Access Levels.
• Identify ADA Flags
  • These should normally not be numerous. It is important to identify people who must receive them but, since they are not importable, the usual process is to edit the people’s records manually after importation.

I. THE (OPTIONAL) PEOPLE DATA PREP WORKSHEET

• The goal is to perform the steps of Paragraph F above as effectively as possible. You can do this your own way, or use the People Data Prep Worksheet.  
• If you decide to use the worksheet:
  • Populate one STOW for each Occupancy in the Facility.
  • Follow the instructions in the “Instructions” Tab of the STOW.  This will help you produce the needed Person Import Worksheets.

J. CREATING RULES FOR THE SYSTEM

Once the Physical and Person databases have been constructed, there remains the task of creating “Rules” for the system.

• Rules are a very powerful feature of BluSKY that differentiates it from its competitors and significantly enhances the effectiveness of the system and the client experience.
   
• Rules are similar to triggers, but much more powerful and much easier to create.
  • Any event generated by the security system can be combined with a video event, and sent over email or text, to any person or distribution group.  
  • Rules can be created at the system, occupancy or even a person-specific level.
  • A schedule can be used to indicate whether a Rule should be executed or not
     

• Basic Rules:

  • Access Control 
    • Controller Offline – if the controller goes offline
    • Controller Online – if the controller comes back online
    • Portal release – if certain portal in the system has been released.
    • Operator activity – if portal in the system has been released by an individual.
    • Credential Used – when specific credential has bee used to access the portal.
    • Access Denied
    • Portal Locked – notify person or group when a certain door is locked.
    • And many, many more
       
  • Alarm and Intrusion 
    • Mass notifications – i.e. send people news; notify them of closures, emergencies, etc.
    • Notify IPS group (Zone or Area) armed or disarmed.
    • Notify IPS point (intrusion point) is active
    • Notify Door Forced or Door Held.
    • And many, many more
       
  • Power Analytics 
    Helps to keep a close eye on system health
    • AC Power Fault
    • Battery Runtime Exceeded
    • Battery Runtime Warning
    • Enclosure Temperature High/Low
    • Power Module Output Power Exceeded
       
  • Video Surveillance
    BluSKY currently supports video integration with Milestone and Salient, and the paring of events generated by the security system with a camera.
    • “Video Motion - Send Email” rule:  When motion is detected in-camera analytics, send an email with a video clip of the event to a person or distribution list. 
    • “Door Forced – Send Email” rule: If a door is forced and has a camera nearby, send a video clip of the event to a person or distribution group.
       
• Rule Creation Guidelines
  • Maybe with client participation, make a short list of the most important events that the client would want to be reported in real time.  
  • Start with a small number of such events; do not attempt to create rules for all possible events at once. 
    • 30 days after the system became operational, review the initial experience with the client – and identify what additional rules are desirable.
  • Identify the people who need to be notified of each event.
    • For any particular event, this could be a single person or several people.
    • Create distribution groups as needed to simplify notification going to multiple people.
    • People such as the Fire Department or the Police that are not part of the database can be added ad hoc to distribution groups.
  • Define notification templates as needed.
  • Refer to the many articles about Rule Creation in BluINFO at https://bit.ly/2DPUko2

• Post Installation Support 
  Click to view EXCEL file: List of Cards not Working.xlsx