Virtual Commissioning and Testing

Purpose

Commissioning test is intended to show that a system is assembled, wired and configured correctly

Description of the presentation

This page should display a list of tests applicable to a given hardware. User should be able to select only those tests he wants to run. Besides test name this list should have Status column (possible statuses are: Passed, Failed, No Run) and Result Description. User should be able to run all/selected tests by clicking “Run All’ or “Run Selected” button. Result Description should identify the reason for test failure without going too deep into technical details.

Commissioning tests

All tests should be executed by correspondent applications (Windows services) servicing the hardware to be tested. Test page initiates test sequence by sending a command that service receives via ServiceBus message

 

1. Network communications

a. Ping. Service issues a network ping request to the controller address. This test is to be executed when the controller’s address is accessible from the service (both reside in the same network or the controller has public IP address)

b. Comm attempts check. Service waits until a communication attempt has occurred from the controller or the timeout has expired

c. Status retrieval. If Blub0x service communicates with the hardware via the third-party API that provides method for a status retrieval service should call this method to get the status of the controller

 

Test is considered successful when at least one of steps above succeeds

 

2. Is Controller configuration loaded

This test should request the configuration and status of all hardware devices connected to the controller. For Mercury test should request statuses of all SIO boards

 

3. Outputs test

Service should request the controller to trigger all connected and configured outputs and analyze the feedback to make sure that the loaded configuration matches the one in the database. For Mercury service should release each configured ACR and send Open command to each configured Control point

 

4. Simulated card swipe

For controllers that support this feature (currently Mercury only) service should perform the following steps:

a. Find one of unused cards that can be used for testing. The card should have a format that has been already loaded into the controller

b. Figure out an access level (or create a new one) that allows access to all of readers serviced by this controller

c. Load test card and access level data into the controller

d. Perform simulated card swipes against all Readers for this controller and analyze the feedback

e. Delete test data from the controller

 

5. Configuration loading

Service should load the full configuration to the controller and analyze the feedback to make sure that no errors have occurred during this process