Technician Table Technician Table EditorEditor

Company: DVTelAcademic advisor: Professor Ehud GudesTechnical advisor: Menny Even Danan

Team:Olga PeledDoron Avinoam

DVTelDVTel

DVTel is a pioneer and dominant market player in the creation,

development, and delivery of Multi-source Intelligence Systems over IP

networks.

One Of DVTel’s SystemsOne Of DVTel’s Systems

Latitude 5.X is a platform which enables its users to manage cameras, sensors, microphones, relay motors etc’.

Its applications are diverse and include security, command and control, transportation management and business intelligence gathering.

BackgroundBackground

Latitude PlatformPlatform

The Problem Domain

Today the information of all the devices is encapsulated in what is referred to as “Technician tables” which are written manually in an XML files.

Every manufacturer has its own XML file with information about the different models that he produces.

The Problem Domain (cont’d)

Different models have many features in common and as a consequence the information is encapsulated in inheritance hierarchy in the XML files.

Searching, editing or changing every XML file is carried out by hand and this process produces many bugs and requires a lot of maintenance.

Example OF XML File<ExtendedType ID="PictureProfileBase" BaseID="" ExternalPluginID="C41128CA-C45E-

4941-B4EA-957C60CAE7E0" EntityType="DVTel.API.Entities.Physical.IPictureProfileEntity>"

 < NumberMetaData PropertyID="Hue" Required="NotSupported >/ " < EnumMetaData PropertyID="NoiseReduction" Required="NotSupported >/ "

 <EnumMetaData PropertyID="WhiteBalance" Required="Required" DefaultValue="Auto"

PossibleValues="Auto,FixedOutdoor,FixedIndoor,Fluorescent,Hold>/ "  < EnumMetaData PropertyID="ShutterSpeed" Required="Required"

DefaultValue="Automatic" PossibleValues="_1_15, _1_30, _1_60, _1_120, Automatic >/ " < EnumMetaData PropertyID="InputFilter" Required="NotSupported >/ "

 < EnumMetaData PropertyID="ExposureArea" Required="NotSupported >/ " < NumberMetaData PropertyID="GammaCorrection" Required="NotSupported >/ "

 < BooleanMetaData PropertyID="BackLightCompensation" Required="NotSupported >/ " < NumberMetaData PropertyID="Sharpness" Required="Optional" MinValue="0"

MaxValue="100 >/ " < EnumMetaData PropertyID="IRFilterMode" Required="NotSupported >/ "

 < NumberMetaData PropertyID="IRFilterOnThreshold" Required="NotSupported >/ " < EnumMetaData PropertyID="DayNightMode" Required="NotConfigurable"

DefaultValue="Advanced >/ " /< ExtendedType>

Example OF XML File (cont’d)

<DeviceExtendedType ID="9520_PictureProfile" BaseID="PictureProfileBase" Model="DVT9520" ExternalPluginID="C41128CA-C45E-4941-B4EA-957C60CAE7E0"

EntityType="DVTel.API.Entities.Physical.IPictureProfileEntity>"  <EnumMetaData PropertyID="WhiteBalance" Required="Required"

DefaultValue="Auto" PossibleValues="Auto,FixedOutdoor,FixedIndoor,Fluorescent >/ "

 /< DeviceExtendedType>

Smart, semi-automatic editor to replace today’s method which will include:

• Graphical User Interface which enables the user to view, edit and create the metadata.

• Query engine.

• Automatic table creator which enables the automatic creation of tables for the various cameras.

System Diagram

ArchiverDirectory

EDB

Latitude client applications

Data Data

Copy of Technician

Table

Copy of Technician

Table

Copy of Technician

TableProgrammer’sComputer

Original Technician

Table

Used by the Archiver in order

to determine what is supported by

the unit

Used by the Directory in order to validate configuration entity in respect to a unit

The programmer will create the

Technician table file

Used by client applications in order to customize the GUI in respect to a unit

CCC

C

New camera to add to the

technician table

Physical Structure

C

C

C

C

Verint model A

Verint model B

Axis model A

Axis model B

Programmer workstation

Software Package Diagram (conceptual perspective)

Verint API

Axis API

Latitude API

TechnicianTable

System

Editor

Software developers responsible of editing/changing the "technician tables".

Software developers of 3rd party pluggable components which must comfort to a well defined interface.

Both types have an established understanding of the system and the knowledge of operating it correctly.

Stakeholders

Main Functional Requirements

Graphical User Interface which enables the

user to view, edit and create the metadata of

each device in a user-friendly environment.

The GUI should be dynamic to adapt to new metadata properties required by Latitude.

Query engine which enables retrieving

Information about cameras and comparing between different

models.

Main Functional Requirements (cont’d)

Main Functional Requirements (cont’d)

Development of components only for the following vendors: Verint and Axis.

Automatic table creator which enablesconnecting to a unit, querying the unit for its capabilities and automatically creates and updates technician tables.

Speed Capacity & Throughput:The number of users that can access the system simultaneously is only one.

Safety & Security:The technician tables may be encrypted.Both encryption and decryption algorithms are provided by the latitude system (which implies a single key is stored in the latitude system).

Portability: Supported operating systems: Microsoft windows XP, Microsoft Vista.

Reliability:The system is not required to withstand certain hardware or software failures, only write an informative message describing the erroneous to a log file.Platform:The system is developed under .NET platform using C# and the development environment will be Visual Studio 2005.

Extendibility:There are number of aspects, with respect to the system, that must be open to extension and closed to modification. These include the following: Additional cameras must be added in a pluggable manner. The abstract concept of technician table may have multiple implementations (the current and only implementation is with XML files).

Scope:Application

Level:User level

Pre-condition:none

Post-condition:A new file was created with the name and location set by the programmer and is now open.

Main success scenario:1. The programmer asks the system to create a new technician table.2. The system displays to the user a list of available vendors.3. The programmer selects the vendor he wishes creating a new technician table.4. The system displays the connection information to be set by the programmer.5. The programmer then sets the connection information of the vendor's camera and confirms.6. The system establishes a connection to the camera of the given vendor and retrieves the features of the model.7. The system queries the latitude system for the set of supported properties.8. The system creates a technician table for the given vendor based on the information retrieved from the camera and the latitude system and notifies the user of the successfulness of the operation.

Extensions (Alternative flows):4.1 The system fails establishing a connection to the given vendor.4.2 It then notifies the user of the fault and logs this information to a file. 4.3 Finally, the system returns to the previous screen. 

Use case UC1: Create new technician table for a selected Use case UC1: Create new technician table for a selected vendor.vendor.

Scope:Application

Level:User level

Pre-condition:The technician table of the vendor is open.

Post-condition:The model is added to the technician table.

Main success scenario:

1. The programmer asks the system to create a new model.2. The system presents the editable properties of the technician table.3. The programmer sets the various properties and confirms.4. The system adds the model entry to the technician table and notifies the user of the successfulness of the operation.

Use case UC2: Create new modelmodel entry entry for an existing vendor.

Scope:Application

Level:User level

Pre-condition:A technician table is open.

Post-condition:none.

Main success scenario:

1. The programmer selects a model from the technician table.2. He then selects an f/w entry of the selected model.3. Next, she selects a profile to edit from the list of profiles.4. He asks the system to edit the selected profile.5. The system presents the editable properties of the selected profile.6. The programmer edits the properties of the profile.

Use case UC9: Edit for each <vendor, model, f/w> a set of profiles.

Scope:Application

Level:User level

Pre-condition:The technician table is open

Post-condition:The properties of the model are being displayed to the programmer

Main success scenario:

1. The programmer selects a model (or f/w of that model).2. He then asks the system to display the information of the selected model(f/w).3. The system displays the properties of the model(f/w) to the programmer.

Use case UC13: Display information of a specific model (optional f/w).

Scope:Application

Level:User level

Pre-condition:the technician table is open

Post-condition:A list of models supporting these properties are being displayed to the programmer.

Main success scenario:

1. The programmer asks the system to present model with specific properties.2. The system presents the programmer a screen and asks the programmer to select the properties of interest. 3. The programmer selected the specific properties and confirms.4. The system displays all the models supporting the specified properties.

Use case UC15: Display models which supports specific capabilities.

We might interact with different versions of the latitude system, which implies changes in the Latitude interface.

For more information please visit : www.cs.bgu.ac.il/~peledo