1 / 35

Technician Table Editor

Technician Table Editor. Company: DVTel Academic advisor: Professor Ehud Gudes Technical advisor: Menny Even Danan Team: Olga Peled Doron Avinoam. DVTel. DVTel is a pioneer and dominant market player in the creation, development,

raymond-mcintosh
Download Presentation

Technician Table Editor

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Technician Table Editor Company: DVTel Academic advisor: Professor Ehud Gudes Technical advisor: Menny Even Danan Team: Olga Peled Doron Avinoam

  2. DVTel DVTel is a pioneer and dominant market player in the creation, development, and delivery of Multi-source Intelligence Systems over IP networks.

  3. One Of DVTel’s Systems

  4. Background • 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.

  5. LatitudePlatform

  6. 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.

  7. 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.

  8. 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>

  9. 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>

  10. Proposed solution • 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.

  11. Proposed solution (cont’d) • Automatic table creator which enables the automatic creation of tables for the various cameras.

  12. System Diagram

  13. Physical Structure

  14. Software Package Diagram (conceptual perspective)

  15. Stakeholders • 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.

  16. 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.

  17. Main Functional Requirements (cont’d) • Query engine which enables retrieving • Information about cameras and • comparing between different models.

  18. Main Functional Requirements (cont’d) • Automatic table creator which enables • connecting to a unit, querying the unit for its capabilities and automatically creates and updates technician tables. • Development of components only for the following vendors: Verint and Axis.

  19. Non Functional Requirements Speed Capacity & Throughput: The number of users that can access the system simultaneouslyis 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.

  20. Non Functional Requirements (cont’d) 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.

  21. Non Functional Requirements (cont’d) • 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).

  22. Use Cases

  23. Main Use Cases

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

  25. Use case UC2: Create new modelentry for an existing vendor.

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

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

  28. Use case UC15: Display models which supports specific capabilities.

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

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

More Related