ELEXON Test Evidence Report for CIMCON Lighting’sDashboards and Alarms (intimation of Normal, Low or Critical conditions) of a particular remote site from any location. CIMCON's

ELEXON Test Evidence

Report for

CIMCON Lighting’s

LightingGale TM

Date: 18/01/13

Version Number: 1.0

Test Evidence Report LightingGale TM

Page 2

Confidential Information of CIMCON Lighting. Unauthorized copying or distribution to third parties without prior written permission is not permitted.

Table of Contents

Introduction ........................................................................................... 3

Test Hardware ........................................................................................ 4

Test Procedures ...................................................................................... 5

Test Group: Test Group 1 ....................................................................... 5

Test Group: Test Group 2 ....................................................................... 9

Test Group: Test Group 3 ......................................................................17

Test Group: Test Group 4 & 5 .................................................................18





Test Group: Test Group 10 .....................................................................37


Page 3


Introduction

This test evidence report has been drafted for the LightingGale Central Management System (CMS) for its approval for use in the unmetered market in Great Britain.

LightingGale is a web based SCADA (Supervisory Control and Data Acquisition) system primarily used to configure, monitor, and acquire various types of data relevant to exterior lighting. Acquisition data includes parameters such as the Voltage, Current, Frequency, Power, Power Factor, Energy, and various status states of the streetlight (on, off, dim level) along with various fault conditions like lamp oscillating, ballast fail, lamp fail, photocell fail, etc. Control data includes setting the lamp states manually or automatically through various scheduling methods. The advantage of using LightingGale is that being a web-based application, authorised users can view the Status, Reports, Trends (graphical representation of various parameters), Dashboards and Alarms (intimation of Normal, Low or Critical conditions) of a particular remote site from any location.

CIMCON's LightingGale software can be configured to work with CIMCON's iSLC1000, iSLC3000 and iSLC3100 lighting controllers.

The below screen outlines the architecture of LightingGale. The control system consists of a central host or Master Control System (MCS) sometimes referred to as the Cloud, one or more Gateways called Data Concentrator Unit (DCUs), Street Light Controllers (SLCs), and a collection of database driven software used to monitor and control remotely located field data elements through a state-of-the-art GUI interface.

The SLC is a hardware device located on the luminaries to which data is transmitted and received. The SLC contains an RF Module, which communicates with the Gateway. A group of SLCs communicates their data to the Gateway via a Zigbee mesh network. The DCUs can transmit the data to the MCS via one of three available interfaces - GPRS, Ethernet, or Serial Network to the software application. In the GPRS case, a carrier specific SIM card is used by the modem to communicate with the carrier cell receiver. From there, it is transmitted over the internet to the centralised software application. The details received through the network are updated in the centralised database. Therefore authorised users can log on to the LightingGale application via a web browser and access the various details stored in the centralised database.


Page 4


LightingGale Architecture

Test Hardware

The details of the hardware devices used for the tests are listed in the table:

DEVICE (WATT)

LAMP DETAILS

SLC ID SLC MODEL WIRELESS GATEWAY ID

WIRELESS GATEWAY

MODEL

56 W PHILIPS CFL LAMP WITH HF REGULATOR

2 CIMCON iSLC 3100

1 CIMCON Wireless Gateway

30 W LED LAMP, Philips Xitanium Programmable LED Drivers

1 CIMCON iSLC 3100

1 CIMCON Wireless Gateway


Page 5


Test Procedures

The test groups evidenced in this report are listed below. The test requirements are based on the Test Specification.

Test Group: Test Group 1

Test Requirements: System Configuration - The operator of the CMS System should demonstrate the software versioning and operating platforms that will be subject to approval.

Test Evidence:

The system runs on a combination of Microsoft Windows platforms. The client software primarily runs on Windows 7 and the server software runs on Windows Server 2008 R2. The operating platforms are detailed below:

DATABASE AND APPLICATION SERVER

Hardware Requirements

Description Minimum Specifications Recommended Specifications

Processor Dual Core Intel® Pentium® Processor, 2.0 GHz

Dual Core Intel® Xeon® Processor (3.0 GHz or higher)

RAM 2 GB 4 GB

Hard Disk 40 GB 80 GB


Page 6


Software Requirements

Component Supported Versions Recommended Version

Operating System Windows Server 2003 SP2,

Windows Server 2008 R2 Windows Server 2008 R2

Internet Information Server (IIS)

7.0/8.0 8.0

.NET Framework 4.0 4.0

Database Server SQL Server 2008 R2 SQL server 2008 R2

CLIENT DESKTOPS

Hardware Requirements

Description Minimum Specifications

Recommended Specifications

Processor 2.0 GHz P IV 3.0 GHz P IV or higher or 1.8 GHz Centrino Duo Processor or any equivalent

RAM 1 GB 2 GB

Software Requirements

Component Supported Versions

Recommended Version

Operating System Windows XP Professional, Windows 2003 Server SP3, Windows 7

Windows XP Professional

Internet Explorer 7.0/8.0 8.0

Microsoft Silverlight 4.0 4.0

Internet connectivity 1 MB/s 2 MB/s or faster


Page 7


The source code of the application is stored in centralised code management software which also stores the version history:

MS Visual Source Safe as the Source Code Manager

Manual test cases are derived for all software enhancements. Each release has a distinct and unique version number:

Release version of the application


Page 8


An “About” page is provided in the software which can be accessed using the Help > About menu; this page also displays the application’s version information.

About page displaying version information

Versions are assigned to the software as follows:

Version Numbers shall consist of 3 numbers in the following format:

A.B.C SPX Hotfix X

A.B.C SPX Patch X

Where

A = Major release version number

B = Minor release version number

C = Bug fix/maintenance release version number.

SP = Service Pack release

Hotfix = Hotfix of the version

Patch = Patch of the version

X = Increment No

A new version number is assigned by setting one of the numbers A, B or C to the next higher sequential number in increments of one (1).


Page 9


The major release version number A is upgraded when:

There are major enhancements and significant new functionality has been added in the software release.

The minor release number B is upgraded when:

There are minor enhancements and/or modifications in the existing functionality.

There is a change in the Graphical User Interface (GUI) objects such as screens, forms, buttons, field displays, menu navigation, and organization of menus, mouse actions, hotkeys, and control keys.

The Bug fix/maintenance release number C is upgraded when:

There are bug fixes or maintenance releases with no change in functionality.


Test Requirements: Security - The operator of the CMS System should demonstrate the procedures which provide secure access to data. Operators should only be able to access data which is relevant to them. Secure access procedures should be demonstrated for the following participants:

HHDC

Suppliers

Customers

Test Evidence:

A valid user id and password is required each time users access the system. The user is associated with a Security Template which restricts their access to system operations and data functions.


Page 10


Valid User ID and Password required to access the system

Functions available to the users are primarily filtered based on their type such as Admin or Regular which can be assigned while creating the same. The Admin users have access to all the menus of the application as well as data of all the devices and no manual assignment of privileges is required. The Regular users have access only to specific menus and no access to any devices; manual assignment of privileges for the devices is required.

User type can be selected while creating a new user


Page 11


Further security can be applied to the users via a menu-wise security template assignment, wherein templates for access to various menus of the application can be created and then assigned to users, so that they see only those menus that are related to their job function.


Page 12


Access to various features of the application can be restricted

Using this feature, read-only access can be defined and applied to users\groups as and when required:


Page 13


Read-only access can be defined in form of template


Page 14


Read-only access can be configured as and when required


Page 15


Similarly, a feature of Device Security is available, administrators can define which user is allowed to view or manage data of which device.

Access to data of specific devices can be restricted for selected users


Page 16


Admin user having access to all menus and data of all devices

Regular user having access to only specific menus and data of no device by default


Page 17


Read-only user having only ‘read’ access


Test Requirements: Synchronisation to UTC - The operator of the CMS System should demonstrate that the CMS System is Synchronised to UTC, either by connection to internet time servers or a radio clock, and are accurate to within ± 20 seconds per month.

Test Evidence:

The application servers and database servers will be synchronised with an internet time server:


Page 18


Test Group: Test Group 4 & 5

Test Requirements for Group 4: Inventory control information - The operator of the CMS System should demonstrate the addition, modification and deletion of Inventory Control information required for the key test scenarios, either manually or electronically. The Data subject to testing is:

Sub-Meter ID

Effective From Data

CMS Unit Reference

Number of Items

Switch Regime

Charge Code

The operator of the CMS System should demonstrate the recording of the audit trail for the entries made above.

Test Requirements for Group 5: Equipment control information - If applicable the operator of the CMS System should demonstrate the addition, modification and deletion of Equipment Control information required for the Scenarios described in Section 4, either manually or electronically. The Data subject to testing is:

CMS Unit Reference

Sum of CMS Controller devices

Switch Regime

Charge Code

The operator of the CMS System should demonstrate the recording of the audit trail for the entries made above.

Test Evidences: Test Evidence for Test Group 4 and 5

The system is not set up to produce a control file as this is a requirement of the Unmetered Supplies Operator (UMSO). It does include however asset management capabilities wherein asset information and attributes of the devices can be stored. Asset data stored in other systems can be easily imported into the system using MS Excel files. Using these features Inventory Control information such as Sub-Meter ID, Effective From Data, CMS Unit Reference, Number of Items, Switch Regime, Charge Code as well as Equipment Control information such as CMS Unit Reference, Switch Regime, and Charge Code can be added, modified and deleted.

The Inventory information stored in form of assets and attributes can be exported in an MS Excel file.


Page 19


View and export assets Information

Once the attributes are imported in to the system, the same can be assigned to the Streetlight Controller devices.

Inventory control information can be added in form of Assets

Inventory control information can also be imported from a file


Page 20


Equipment control information can be added in form of attributes

The attributes can be applied to the SLC (streetlight controllers)


Page 21


The assets of the SLCs can be viewed right from the map


Page 22


Any action performed for management of assets such as add, modify, and delete, are logged in form of comprehensive audit trail records:

Audit trail for actions performed on assets

The audit trail can be generated based on the users and date range selected.

The audit trail log displays the action carried out, the date when the action was performed, the user that performed the action, the old value before the change and the new value after the change.


Page 23



Test Requirements: CMS Issue Instructions - The operator of the CMS System should demonstrate the issuing of operational switching times and power level instructions for CMS Units in the CMS System for the following scenarios:

Scenario 1 - Switch Regime 999;


Scenario 3 - Control Failure (no data for a CMS Unit);

Scenario 4 - Revised Data after control failure (following day)


Test Requirements: Record operational switching times and power levels - The operator of the CMS System should demonstrate the recording of operational switching times and power levels for CMS Units in the CMS System for the following scenarios:





The operator of the CMS System should demonstrate the audit trail for the above scenarios.

Test Evidences: (Test Evidence for Test Group 6 and 7 are combined)

Dimming schedules can be defined to reduce the lamp’s light for specific intervals. SLC Dimming schedule templates can be created based on parameters such as Start Time, End time, and Frequency Percentage (%). This template is configured by specifying the parameters for making decisions. It enables dimming (flux reduction) for individual SLCs, groups of SLC(s) or the whole system.


Page 24


Start Time End Time Dimming % Power %

Sunset 6:30 PM 100 0

6:30 PM 8:00 PM 75 25

8:00 PM 4:30 AM 50 50

4:30 AM 5:30 AM 75 25

5:30 AM Sunrise 100 0

Switch Regime 999 Schedule


Page 25


Assign Switch Regime 999 Schedule to SLCs


Page 26


View the configured regime and the one stored in the device


Page 27


Start Time End Time Dimming % Power %

12:00 AM 10:00 AM 0 100

10:00 AM 12:30 PM 40 60

12:30 PM 3:00 PM 70 30

3:00 PM 5:30 PM 50 50

5:30 PM 11:59 PM 40 60

Switch Regime 998 Schedule


Page 28


Assign Switch Regime 998 Schedule to SLCs

View the configured regime and the one stored in the device


Page 29


View asset information

Control Failure for Multiple CMS Unit References and Revised Data after Control Failure (Following Day):

Test was executed with a 56 W CFL lamp and a 30 W LED lamp, to which the 999 and 998 switch regimes had been assigned respectively. Test was executed over a period of three successive days.

Switching points for the lamps affected due to connectivity failure are not added to the event logs till the switching points are available. Once the switching points are available, say for e.g. the very next day, a new version of event log listing all the switching points for a day will be created along with any event logs of the current day. The newer event logs will always display up-to-the-minute record of all the events that occurred for the lamps associated with the Sub-Meters.

Day 1: Disconnected data cable, to trigger connectivity failure.

Day 2 (morning): Reconnected the cable. Empty event logs (only file header and file trailer) for the lamps (for Day 1) are generated.

Day 3: two event logs (one for day 1 and one for day 2) are generated. The logs contain all the correct switching points for the respective days.

The following screens show these event logs:

Empty event logs sent on Day 2 (for Day 1)


Page 30


Event logs sent on Day 3 (for Day 1)

Event logs sent on Day 3 (for Day 2)


Page 31


Event Audit Trail


Page 32


Lamps on 24X7 with no additional switching events:

If lamp is ON 24X7 with no dimming or other events, an ‘ON event’ is reported around midnight each day.

Start Time Dimming % Power %

12:00 AM 0 100

Switch Regime 998 Schedule for 24X7 burning with no additional switching events


Page 33


Event log for the ‘ON event’ at midnight


Test Requirements: Generate Operational Event Log - normal processing and control failure - The operator of the CMS System should demonstrate the sending of daily operational event logs of the operational switching times and power levels for specified CMS Units to the MA in the specified format for the following scenarios:





The operator of the CMS system should demonstrate a control failure (no data for a CMS Unit) through use of the correct information flag as per Scenario 3.

Operational Event Log - revision to previously reported data The operator of the CMS System should demonstrate that data can be revised by either issuing a refresh or an incremental operational event log (CMS and MA Separate Systems) to the MA in the specified format or if applicable the transferring of revised data (CMS and MA integrated System) from a previous control failure. (Scenario 3) The Refresh or Incremental Flow should cover:

Refresh Flow

o A complete refresh of the operational event logs which includes previously unknown data

o A complete refresh of the operational event logs which includes data which has been amended


Page 34


Incremental Flow

o An incremental update of the operational event log which includes previously unknown data

o An incremental update of the operational event log which includes data which has been amended.

The operator should demonstrate that the operational event log has been retained for audit purposes and that the audit trail is correct.

Test Evidence:

Event logs are generated every morning at a scheduled time. The event log is generated per sub-meter per day in the application installation directory. A folder for each client is created and the logs are stored in folders named as per the respective Sub-Meter IDs.

Folder for sub-meter Gate001


Page 35


Event Log Audit Trail

An audit trail record is generated for the generation of each event log.

Event log audit trail


Page 36



Test Requirements: Volume and Performance - The operator of the CMS System should provide evidence of volume and performance tests completed by the applicant as part of their system testing, to the accredited test agent so that compliance with operational timescales can be assessed.

Test Evidence:

Details of the volume and performance tests are as follows:

Test machine Details:

2.4GHz Intel(R) Xeon(R) CPU

1 GB RAM

40GB HDD

64-bit Windows Server 2008 R2 Enterprise

Test for event log generation was performed for 10,000 street light controllers wherein each controller had 5 switching points per day. The time taken to generate and download a daily event log was 7 seconds.

Test for audit trail retrieval was performed for 10,000 street light controllers wherein each controller had 5 switching points per day. The time taken to retrieve the audit trail records for each controller in a page containing 16 records was 3 seconds. The same amount of time was taken to export the data to an MS Excel spreadsheet.

Test for adding 5 switching points was performed on 10,000 controllers. 90 seconds was the time taken to send (5 x 10,000) = 50,000 switching points to the controllers.


Page 37



Test Requirements: Operational Event Log - File format - The operator of the CMS System should demonstrate that the operational event logs are in the specified format, as per BSCP5201 Section 4.5.3.3 (c).

Test Evidence:

Event logs are generated in a way that meets the specified criteria:

Power Data Associates has received and successfully processed an event log file from CIMCON and confirmed that it was in the correct format. Power Data Associates will provide this confirmation in writing to ELEXON.

Filename: controlmmmmmmmyyyymmdd.log

where:

mmmmmmm = Sub-Meter ID (alphanumeric)

yyyymmdd = date of inventory

log = file extension with all characters in lower case

File header: HMMMMMMMYYYYMMDDVVV

where:

H = header identifier, H

MMMMMMM = Sub-Meter ID (alphanumeric)

YYYYMMDD = effective from date

VVV = version number

File body: UUUUUUUUUUUUNNNNNNRRRCCCCCCCCCCCCC

where:


Page 38


UUUUUUUUUUUU = CMS Unit Reference (alphanumeric)

NNNNNN = Number of items

RRR = Switch Regime (999 or 998)

CCCCCCCCCCCCC = Charge Code

File trailer: TNNNNNN

where:

T = trailer identifier, T

NNNNNN = total number of lines including header and trailer

Documents

ELEXON Test Evidence Report for CIMCON Lighting’sDashboards and Alarms (intimation of Normal, Low or Critical conditions) of a particular remote site from any location. CIMCON's