UCC Overview and Concepts

Overview

UCC is a generic router that allows the master device to send any data to any slave. It runs on the PC associated with the master device and receives input from a TEF server running on the master device. The TEF server uses a standard Symbian plug-in to convert test step commands into instructions which are sent to the UCC. You must configure the plug-in for your test environment using an INI file on the master device.

Concept

The main concepts involved here are:

  • Master: The master device is the device under test. It can be either a development board, a phone or an emulator.

  • Slave: The slave device exists to provide a peer for testing peer-to-peer communications. It must be under the control of the same test script.

  • Service: A service is an executable with a configurable interface that is called by the UCC. The purpose of a service is to enable the UCC to send commands to a pre-existing executable. Each service must be custom built to convert calls from the UCC into calls to the target API. Symbian provides services that allow the UCC to control STAT and TestDriver.

  • Service PC: A device (either Master or Slave) which runs a UCC service.

UCC components

The main components of UCC are:

  • UCC.exe: This runs on the Master PC and receives commands from the script running on the Master device. It then sends or receives data to or from the services running on the Slave PC (SyncService.exe and TestDriverService.exe).

  • TestDriverService.exe: This runs on the Slave PC and waits to receive data from the Master PC about TestDriver commands (for example, to build and run a testdriver suite).

  • SyncService.exe: This runs on the Slave PC and waits to receive data from the Master PC about synchronisation commands (for example, to start running a test block).

  • UCCControlTE.exe: This refers to a standard TestExecute test server, which is used to communicate with the UCC running on the PC. It must run on the master device so that services can communicate with UCC. It provides test steps which can be run using the TestExecute script.

How UCC works

The testing of peer-to-peer communications requires an environment in which two or more Symbian devices can run synchronized, automated test scripts. The Use Case Controller forms part of the tool chain which enables such tests.

The test environment comprises a Symbian OS device (the Master) and one or more Symbian OS emulators (Slaves). The device and each of the emulators has an associated PC. The PCs must be connected or networked.

The tests themselves consist of a Test Execute Framework (TEF) script that runs the on the Master and which controls the execution of TEF scripts running on the slave emulator(s).

Test steps in the Master’s test script are able to send instructions and data to test scripts running on slave devices.

The UCC is a generic router that allows the Master to send any data to any slave. It runs on the PC associated with the Master.

The UCC receives input from a TEF server running on the Master. The TEF server uses a standard Symbian plug-in to convert test step commands into instructions which are sent to the UCC. You must configure the plug-in for your test environment using an INI file on the master device.

The UCC distributes the commands that it receives. You must configure it with information about each possible destination using an INI file on the UCC PC. Each destination must be a running executable that implements the CService API. Symbian provides two services as part of the Bluetooth test suite. You may also create your own.

Service implementations may run on the same PC as the UCC or on networked PCs. Multiple instances of the same executable may run concurrently but the UCC must be configured to treat them as separate services.

The CService API includes a single function with a single parameter: virtual int RunCommand (const CCall& aCall)=0. Each service implementation requires a configuration file that details the ways in which the parameter can be used – in other words a file that describes its interface. The configuration file, another INI file, is required by the UCC and must reside on the UCC PC.

The two service implementations that Symbian provides, a synchronization service (which controls the STAT tool) and a TestDriver service (which controls the TestDriver tool), both run on a slave PC. Each of these also has a configuration file which you might need to modify.

The final links in the test environment chain, the TestDriver and STAT tools, control the TEF running on the slave device.

The complete environment is shown in the following diagram.

UCC architecture


UCC architecture

The diagram shows the test environment for Bluetooth testing using a development board or device as the master and single slave. The UCC, and the Synchronisation and Bluetooth services allow the TEF on the master to drive and synchronize the TEF on the slave.

The functionality required by the STAT and TestDriver tools dictates the information that has to be transported through the UCC PC and the service interfaces. You need this information, along with information on the ports and/or network addresses that you are using, to edit the various configuration files. All of the configuration files are provided by Symbian.