org.ocap.test

Overview | Package | Class | Use | Tree | Deprecated | Index | Help

PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES

## Package org.ocap.test

OCAP testing communications.

See:
Description

Class Summary
OCAPTest | The purpose of this class is to provide a very simple communication channel between the OCAP implementation under test (IUT) and the test server.

## Package org.ocap.test Description

OCAP testing communications.

OCAP testing requires the test applications executing on OCAP devices be able to communicate with an Automated Test Environment (ATE) in a manufacturer-independent manner. This differs from the MHP test environment, in which MHP device manufacturers provide manufacturer-specific implementations to communicate between an ATE and an MHP device. The need to communicate with an ATE in a manufacturer- independent manner indicates that the OCAP devices SHALL communicate with the ATE using a common, defined communications mechanism.

Since OCAP devices, by definition, must support TCP/IP and UDP/IP for interaction channel protocols, TCP/IP and UDP/IP sockets have been chosen as the mechanism by which OCAP devices will communicate with an OCAP ATE. The interaction channel provides either TCP/IP or UDP/IP protocol, via the RF connector labeled 'Cable In' on the OCAP Host Device, and the CableCARD. Though the OCAP Host Device supports both TCP/IP and UDP/IP, only one of them SHALL be used for the ATE, according to the type of CableCARD, once communication between the ATE and Host device has been established (see item b) below).

## OCAP compliance testing

Due to the large number of OCAP Host Devices which are expected to be made available by manufacturers during certification testing "waves", OCAP compliance testing will need to be able to take advantage of a common, scalable hardware infrastructure.
The proposed connectivity diagram is shown below in Figure W-1:
Figure W-1 - Connectivity Diagram .

This diagram is intended to show how multiple ATEs can be connected on a common IP network with multiple OCAP Host Devices. On the left is a single Out-Of-Band (OOB) channel which can transmit a location of a common test Monitor Application to all OCAP Host Devices being tested. In-band (IB) delivery channels are used to stream test applications, and are controlled by a particular ATE instance. All of these IB and OOB channels are multiplexed onto a common RF cable which is shared by all OCAP Host Devices being tested.
Each OCAP Host Device that is being tested is associated with a test harness comprised of reset, IR, and media capture subsystems. These subsystems are controlled by a particular ATE instance. The ATE instances are shown on the right side of the drawing.
At configuration time, an instance of the ATE is associated with a particular IB delivery channel, an OCAP Host Device being tested, and its associated test harness components.
During compliance testing, a particular OCAP Host Device establishes a communication channel with a particular instance of the ATE. The ATE is responsible for preparing test applications to be loaded onto the OCAP Host Device (via its associated IB delivery channel), and for responding to requests made by test applications executing on the OCAP Host Device being tested.

The scenario for establishing communications between an OCAP Host Device being tested and an ATE is as follows (details are addressed in the CableLabs' ATE documentation):
a) The ATE uses the "reset for next test" mechanism to set the OCAP Host Device being tested into a known default state, ready to receive the test-application. This involves a power-cycle of the OCAP Host Device being tested.
b) The ATE begins sending IP datagrams to the IP address of the OCAP Host Device it is associated with.
c) The OCAP Host Device powers up out of reset and reads an XAIT from the out-of-band communications channel, signaling the OCAP Host Device to load a Test Monitor Application (an unbound application) from an in-band communications channel.
d) The Test Monitor Application invokes `OcapSystem.monitorConfiguredSignal()` to enable conformance testing APIs (`org.ocap.test.OCAPTest`). When monitorConfiguredSignal is called, the implementation will enable the conformance testing APIs (see org.ocap.OcapSystem.monitorConfiguredSignal for details and OCAP testing communications below).
e) Test Monitor Application requests configuration parameters including information on the initial channel to tune to using the communications channel established in step c.
f) Tuning to the specified channel initiates a service containing the bound testlet application.
g) Test application executes on OCAP Host Device, communicating with the ATE as required via the communications channel opened up in step c.

## OCAP testing communications

OCAP testing requires that test applications executing on OCAP devices be able to communicate with an Automated Test Environment (ATE) in a manufacturer-independent manner. The need to communicate with an ATE in a manufacturer-independent manner means that OCAP Host Devices SHALL communicate with the ATE using a common, bi-directional interaction channel. In an effort to isolate OCAP Host Device implementations from the need to implement interaction channel protocols, which are necessary only for use in compliance testing, the class `org.ocap.test.OCAPTest` has been defined. This class presents an API to test framework classes which can be used for compliance testing. The conceptual diagram of this communications structure is presented below:

Figure W-2 - Interaction Subsystem Design Diagram.

Overview | Package | Class | Use | Tree | Deprecated | Index | Help

PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES