Home Papers Reports Projects Code Fragments Dissertations Presentations Posters Proposals Lectures given Course notes

Component Oriented Design of the SEESCOA Common Test Case: The Controller and Zoom Behaviour

Werner Van Belle1* - werner@yellowcouch.org, werner.van.belle@gmail.com

1- Programming Technology Lab (PROG) Department of Computer Science (DINF) Vrije Universiteit Brussel (VUB); Pleinlaan 2; 1050 Brussel; Belgium

Abstract :  This document describes the design of two components in the seescoa component system: the controller (or directory service, responsible for interconnecting most components) and the zoom behavior, responsible for providing linkage between the behaviour of two or more cameras.

Keywords:  camera zoom synchronized behavior distributed agreement coordination seescoa
Reference:  Werner Van Belle; Component Oriented Design of the SEESCOA Common Test Case: The Controller and Zoom Behaviour; SEESCOA Deliverable 3.5; 10 of 126 pages; October 2001
FilesDesignControllerZoom4.pdf, SEESCOA-D3dot5-DesignTestCase.pdf



This document describes the design of two components. The Controller component and the CameraZoomBehaviour component. The first component takes care of setting up interconnections between components, and the second takes care of zooming cameras and coupling the zoom behaviour of a number of cameras. All components are part of a test case for the SEESCOA project.

component Controller


The controller his functionalities are described as follows:

The controller is not responsible for the following:

The controller in the second period of this project (year 2 to 4) can be extended to

Use Cases

Boot up

The boot up of the camera system contains two phases. The first phase covers the startup of the master-server, which also boots the controller. In the second phase, all cameras are looked up and new component systems can connect.

Phase 1: Master Component System Boot up

Phase 2: Client boot up

Component Join & Disjoin

Components can subscribe themselves to retrieve notification of certain new components within the system. For example, a user interface component would like to subscribe to new cameras. The user interface component will receive from the controller a connect message when a new camera joins (or is created).

Disconnecting component can be initiated from anywhere. Every delete command must be send to the controller, which will ask all components to disconnect themselves. If they don't the controller will take action. We will now illustrate connecting and disconnecting



Unwanted Component Disconnection & Component System Disconnection

At the moment a component disconnects because there was an error (crash in the component) or a network failure, all dependent components will be notified with a HasDisjoined message. The messages which trigger such an action are


port Component (noi=1)

port ComponentSystem (noi=1)

multiport Controller (noi=1)

Message Traces

Camera Component System Boot Up

Master Component System Boot Up

component ZoomBehaviour


This is one of the plug in components, which is added to the system to show its flexibility.

Use Cases

Logging of zoom-events

It is possible to log zoom events. If we want this we should connect to the zoom behaviour zoom changed port.

Selection of zoom events

It should be possible to select (prioritise) between a number of camera zoom events. If for example, 2 users are zooming in at the same time, together with an operator on the camera, the zoom behaviour controller should select one suer and stick to him during a certain period of activity.

Coupling of Zoom Behaviours

It should be possible to couple two (or more) cameras, such that the first camera zooms in while the second one zooms out. The constraints placed upon the zoom will be simple linear equations.


port Component (noi=1)

port Camera (noi<=1)

We will use a port to the camera status to obtain information about the maximum zooming parameters. This port is temporary. After obtaining the values this port is not used anymore.

port ZoomRequest (noi=1)

This is the port offered by all cameras, which we have to implement in order to intercept certain zoom events.

multiport ZoomChange (noi=1)

This port is necessary for anybody interested in zoom-change events. This is a stripped down interface of the camera-settings port and will be used by other ZoomBehaviour components.

port ZoomEvent (noi>=0)

This port is necessary for anybody who wants to report a ZoomChanged event at this controller.

port Behaviour (0<=noi<=1)

This port is used to change the formule used in each controller to react to ZoomChanged events.

port UiDescription (0<=noi<=1)

This port can be used by anybody to receive an XML description of the behaviour port.

Example Message Sequences

Logging of Zoom events

Coupling of 2 cameras

This is an example of two cameras coupled together.

Coupling of 3 cameras, A with B, B with C

Below is an example of 3 cameras coupled together. The first is coupled to the second, the second is coupled to the third. The third camera is not immediately connected with the first.