KSENIA LARES Documentation
Table of Contents LIST OF TABLES LIST OF FIGURES 3 3 DOCUMENT CHANGE HISTORY 5 CONNECTING THE DEVICE 6 SETTING DEVICE ADD C4 SERVER TO PHONEBOOK IN BASIS AS RECEIVER SET SIA COMMUNICATION PORTS AND NULL PACKETS SET ACTIVE UDP COMMUNICATION PORTS HOW IT WORKS – COMMUNICATION SIA – PASSIVE ACTIVE UDP REQUESTS COOPERATION OF SIA AND UDP PROTOCOLS FICTIVE UPLOAD USERS: ANALOG INPUT LEVEL FUNCTIONS INFORMATION ON DRIVER DRIVER HISTORY HARDWARE COMPONENTS AND COMMUNICATION SUPPORTED CONNECTED DEVICES KSENIA
TFE020A BATTERY FAILURE TFE030A FUSE FAILURE TFE040A DETECTOR FAILURE TFT010A UNIFIED TIME SETTING TIME ON DRIVER STARTUP TFT020A UNIFIED TIME SETTING TIME WHEN CHANGED ON DEVICE TFT021A UNIFIED TIME – PERIODICAL SYNCHRONIZATION TFT040A UNIFIED TIME – TIME ZONES SUPPORT TFC010A CONTACT ACTIVATION AND DEACTIVATION TFC011A CONTACT MONITORING TFC030A AREA ARMING AND DISARMING TFC031A AREA ARMING FAILURE TFC040A DETECTOR BYPASS AND UNBYPASS TFC050A ACTIVATING TEST MODE ON DETECTOR TFC051A ALARM WHILE IN TEST ON
FIGURE 2: SCHEMA ................................................................................................................................................
Document Change History Date 5.8.
Connecting the Device This section describes connection between Ksenia lares devices and C4 Server. Before you can use driver, it has to be done some configuration in device with configuration software Basis. Steps in Basis are: 1. Add C4 server to Phonebook in Basis as receiver 2. Set Receiver and Application ID 3. Set SIA communication protocol (NULL packets included) and Active UDP 4.
Set SIA communication ports and NULL packets Server port Client Port NULL Packets It is used for checking communication (like heart beat).
Set Active UDP communication ports Ksenia lares – Documentation Page 8
How it works – communication There are used 2 communication protocols simultaneously: SIA for passive receiving packets Active UDP asking for getting states of system By Active UDP we can identify and set actual real state system (for detectors, subsystems, outputs, peripherals) SIA – passive When state is changed, control unit is sending packet with information and we process it. Every 10s device sends NULL packets and we can check that communication is OK.
Own packets AA AB AC AD AE First analog level Second analog level Third analog level Fourth analog level Fifth analog level Active UDP requests If we want some information from central units we have to requests explicit. After that we can parse response from device. In this protocol aren’t a lot of information and therefore we have to use it with SIA cooperation.
In device tree have to be device type Keyboard under Central Unit with type PIN. In C4 menu “Persons” we have to create company like “Positions” and there creates users like “Positions 1” to “Positions 999”. At each user we have to properly fill “Internal number”, which is position number and add to each user PIN (Code is unimportant). It is possible do it with import users. Finally we have to add access to users for devices.
Information on driver It is driver for Ksenia devices. Driver History Version 1.0.0.1 – first version Hardware Components and Communication Communication protocol is described in section “Connecting the Device” Supported Connected Devices Device Name Ksenia Lares 16IP Ksenia Lares 48IP Ksenia Lares 128IP Description Up to 16 zones Up to 48 zones Up to 128 zones Version Firmware: 1.5.1104 Firmware: 1.5.1104 Firmware: 1.5.
Setting Time Interval How often driver sets time to system 1 hour Table 2: Specific Buss Controller properties Central Unit Property Name Meaning Device Type Type of Central Unit (16IP/48IP/428IP) Standard Value Lares 16IP Sample value Table 3: Specific Central Unit properties Group Property Name Meaning Standard Value Address Arm Instantly Defines address of subsystem (1-20) Defines arm type if Command ARM is send (Arm Instantly or not) Sample value false Table 4: Specific Group propertie
Analog Input – level (as Output) Property Name Meaning Address Defines level analog detector (input) state (Level1 – Level5) Defines, what kind of event will be log to event in C4 Event Level Standard Value Sample value Info Table 9: Specific Analog Input - level properties Keyboard Property Name Meaning Address Defines, whether the bus controller usage is enabled Defines credential type Supported Credential Type Standard Value Sample value PIN Table 10: Specific Keyboard properties Suppor
Status Information Display Kseni lares status information is displayed for the following components: Bus Controller Status Unknown Normal Description Bus controller status is unknown. Bus controller is running and driver is operational. Table 12: Buss Controller statuses Central Unit Status Unknown Normal Tamper Description Central Unit status is unknown. Central Unit is running and driver is operational.
Table 17: Peripheral statuses Analog input Status Unknown Normal Tamper Bypass Description Analog input status is unknown. Analog input is running and driver is operational. Analog input is in Tamper Analog input is bypassed Table 18: Analog input statuses Analog input - level Status Unknown Normal Open Description Analog input – level status is unknown. Analog input – level is running and driver is operational.
KSENIA LARES INTEGRATION TESTS Ksenia lares – Documentation Page 17
Preparations for Integration Tests Necessary Equipment Integration tests require the following items: Item Windows XP or higher running PC Kseni lares Ksenia Keyboard Ksenia Reader Expander – for analog input Key ring Number of items min.
Preparing the Central Unit for Testing C4 version: C4 2013 SP6 Kseni lares version: FW 1.5.1104, SW Basis 1.
Example of setting BusController: Connection Connect the central unit according to the installation documentation and this scheme.
TCF000A – Duplicated Addresses This test checks the presence and behavior of the duplicated address check for particular device types. Purpose of the test is to ensure, there’s no duplicated items in device configuration tree, representing the same object (e.g. the same detector created twice in configuration) Test Steps 1. Stop the endpoint when running 2. Create two devices of the same type that are identified by the address, in the device configuration tree. 3.
TCF010A – Missing HW Item This test verifies behavior of the driver in case the device configuration tree is incomplete. In that situation the driver must, whenever it receives an event from device, log the Missing Device event on the nearest parent node of the device configuration or the driver node itself. Test Steps 1. 2. 3. 4. Stop the endpoint when running Create an incomplete configuration tree with missing device Start the endpoint Generate some activity on the missing device Expected Results 1.
TCF020A – Property Value Out OF Range This test verifies behavior of the driver in case the configuration value is out of the defined range. It also verifies that driver detects such an error during its starting sequence. Particullary, it is important to check the validity on device addresses and communication timing settings. Test Steps 1. Stop the endpoint when running 2. Change the property value over the maximum allowed limit. 3. Start the endpoint Expected Results 1.
TCF030A – Attempt to Connect With Invalid Connection Password This test verifies behavior of the driver during communication establishment process, when an invalid connection password, user name or encryption key is defined in device tree configuration. Not implemented. UDP requests are without password. Only for commands is password sent, but system doesn’t response about invalid password.
TRE000A – Connection Lost This test verifies behavior of the driver in a case of connection drop between C4 server and the device. Test Steps 1. Start the endpoint and wait for communication establishment. 2. Drop the connection on the switch or router, in such a way that the Windows system still detects the Ethernet connection* 3. Wait for the disconnection detection 4. After circa 30 seconds, the driver attempts to reconnect. Wait until the attempt is finished. 5. Recover the connection 6.
TRE010A – Communication Lost This test verifies behavior of the driver in case of lost communication between network module and device – there is no disconnection on transport layer. As an example it can be interruption between RS232/TCP converter and the device panel, where TCP connection remains connected. Not Implemented. Connection direct to device.
TRE020A – Establishing Communication with Changed Communication Password This test verifies behavior of the driver when using communication password, username or encryption key and checks if there’s correctly implemented possibility to change the password,username or encryption key to other than default values. Not implemented. UDP requests are without password. Only for commands is password sent, but system doesn’t response about invalid password.
TRE030A – Reading Events from Device Historical Log This test verifies behavior of the driver when transferring events from the device historical log after establishing communication. Standard behavior is that the driver reads all events from the device historical log beginning from its last successful communication (e.g. after the communication failure) Not supported by current protocol (not supported by manufacturer).
TFA010A Intrusion Alarm on Detector This test verifies behavior of the driver’s implementation of alarm events processing in Alarm systems or systems with similar functionality. Test Steps 1. 2. 3. 4. Set the detector to the armed mode (e.g. arming the corresponding area) Issue an alarm on detector Restore the alarm on detector Confirm the alarm from C4 UI. Expected Results 1. 2. 3. 4. The detector state is set to the Alarm. The corresponding areas states are set to the Alarm.
TFA012A Tamper This test verifies behavior of the driver when processing the events about the device tampers on Access systems, Alarm systems or devices with similar functionality. Test Steps 1. Issue a tamper on detector, while detector is in disarmed area 2. Restore the tamper 3. Confirm the alarm from C4 UI Expected Results 1. Until the alarm confirmation, the detector has status “Tamper” 2. Following events are stored in audit log: 28.12.2012 10:33:09 Tamper on 'DEVICE'. 28.12.2011 09:34:08.
TFE010A Mains Failure This test verifies behavior of the driver in case of mains failure of the device that is backed up by battery or other additional power source. Test Steps 1. 2. 3. 4. Disconnect the mains power Wait until the disconnection is detected (on some device might take several minutes) Reconnect power Wait until the reconnection of power is detected Expected Results 1. Following events are stored in audit log: 28.12.2012 10:33:09 Mains fail 'DEVICE'. 28.12.2011 09:34:08.
TFE020A Battery Failure This test verifies behavior of the driver event handling in case of battery or other backup power fault. Test Steps 1. 2. 3. 4. Disconnect the backup power Wait for the disconnection detection Reconnect the backup power Wait for the reconnection detection Expected Results 1. Following events are stored in audit log: 28.12.2012 10:33:09 'DEVICE'. – battery failure 28.12.2011 09:34:08.82 'DEVICE' battery restored.
TFE030A Fuse Failure This test verifies behavior of the driver and handling of the events from device in case of fuse failure. Not supported by device.
TFE040A Detector Failure This test verifies behavior of the driver and handling of the events from device in case of detector failure. Not supported by device. Only tamper.
TFT010A Unified Time Setting Time on Driver Startup This test verifies correct implementation of the unified time management in driver. Driver is required to set up the time on the device after the communication is established. Test Steps 1. Set the device time 60min back 2. Start the endpoint 3. After the endpoint starts, check the time on device Expected Results Only Set time and store in to Trace log.
TFT020A Unified Time Setting Time When Changed on Device This test verifies correct implementation of the unified time management in driver. Driver is required to set up the time whenever the device time is changed (e.g. on keypad). Test Steps 1. Start the endpoint 2. Set the device time 60min back 3. During next 5 minutes the time should be synchronized again. Expected Results Only Set time and store in to Trace log.
TFT021A Unified Time – Periodical Synchronization This test verifies correct implementation of the unified time management in driver. Driver is required to keep the device time synchronous with C4 server time. Test Steps 1. 2. 3. 4. Set the value of property Time setting interval to 5 minutes Start the endpoint Set the device time 60min back During next 5 minutes the time should be synchronized again. Expected Results Only Set time and store in to Trace log.
TFT040A Unified Time – Time Zones Support This test verifies correctness of the time zones support in the driver. C4 provides support for the time zones automatically, when the driver keeps the C4 standards. Device log is not accessible. Events are store in C4 time (Without time parameter).
TFC010A Contact Activation and Deactivation This test verifies behavior of the driver implementation for input/output contact monitoring and controlling support. Test Steps 1. Execute command “On” on contact 2. After the contact is opened, execute command “Off” on it. Expected Results 1. When contact is activated, its status is Open 2. When contact is deactivated, it’s status is Normal 3. Following events are stored in audit log: Command 'On' to 'DEVICE' 'DEVICE' opened.
TFC011A Contact Monitoring This test verifies behavior of the driver implementation for input contact monitoring support. Test Steps 1. 2. 3. 4. 5. 6. 7. 8. On the contact set the property MessageLevel to Info Reinitialize the endpoint Activate the contact on device Deactivate the contact on device Change the property MessageLevel to Alarm Reinitialize the endpoint Activate the contact on device Deactivate the contact on device Expected Result 1. When contact is activated, its status is Open 2.
TFC030A Area Arming and Disarming This test verifies behavior of the driver implementation for handling arming and disarming events from device and controlling the operations from C4 UI. Test Steps 1. 2. 3. 4. Execute command Arm on area in C4. Disarm the area using keypad. Arm the area using keypad Execute command Disarm on area in C4. Expected Results 1. Area status is Armed after step 1, then Normal, then Armed after step 3 and then again Normal. 2.
TFC031A Area Arming Failure This test verifies behavior of the driver implementation for handling arming failures. This usually happens when detector in area is activated at the moment of arming. Not supported by system, there is no information in protocol, that Arm isn’t done.
TFC040A Detector Bypass and Unbypass This test verifies behavior of the driver implementation for detector bypass support. This test is applied to Alarm systems and Fire alarm systems or systems with similar functionality. In Fire alarm systems it is usually considered as detector disable. Test Steps 1. 2. 3. 4. Execute command “Bypass On” on detector Execute command “Bypass Off” on detector Bypass the detector using keypad or device panel Cancel the bypass on the detector using keypad or device panel.
TFC050A Activating Test Mode on Detector This test verifies behavior of the driver implementation for test mode support. This requires to correctly logging appropriate events, setting the devices to correct state and possibility to set the state from starting the Test mode from C4 UI. This test applies to Alarm systems and Fire systems with support of Test mode on detectors. Not supported by device.
TFC051A Alarm While In Test on Detector This test verifies behavior of the driver implementation for test mode support. This test is focused specifically to check the handling alarm on detector whilst in test. This test is applied to Alarm systems and Fire alarm systems with support of Test mode on detectors. Not supported by device.
