General System Overview

TMS System

General System Overview

TMS System Overview

Introduction The system's main task is to register incoming events from alarm panels after the receiver processed them, and to show it to the operator in an ordered, easy to read way. Another task is to help the operator in effectively handling events that require user interruption. Naturally, the system also suits numerous other requirements arising from the need of a secure and comfortable use. When we developed the TMS system, our goal was to use all advantages of modern technology while respecting our customer's needs and experiences with previous versions. With all these requests and experiences taken into consideration, we created a modular architecture which we used in developing the TMS monitoring system. Because user requirements greatly differ when we are talking about a small, compact monitoring central on one computer supporting a small number of customers, or a bigger system with multiple computers and expanded functionality supporting a large number of customers, there are two versions of TMS systems at the moment: TMS Light and TMS Pro. The two systems use the same modules, contain the same data (so switching between the two versions is really simple) and same functions for the system users, but the modules' structures are different. The main difference between the two versions is that the TMS Light runs in a "single computer mode" that is suitable for small monitoring centers, while the TMS Pro is for monitoring centers that hire multiple operators in multiple workplaces scattered across the country. 1. The TMS system's logical structure: The TMS system is a multi-module open architecture software. The following picture shows the system's basic architecture: Interface module 1 ... Interface module 2 Tools
(OrMEBackup, Datacenter, ...)

Operator module (OrME.exe)

Database Accessory tools Administrator module (OrMEAdmin.exe)

That the specific tasks are handled by different modules come with numerous advantages. The whole system is really flexible, making it possible to customize it for different application requirements.

http://www.tell.hu

TMS System

General System Overview

Every module of the software system is capable of supporting multiple languages. The language modules can be easily integrated into the system. In order to understand the OrME system's architecture, let's discuss the tasks of the different components and their interconnections in detail. 1.1 The database The database is the foundation of all functions in the system. The stored data can be divided into several groups:

Customer data. (Name, address, phone numbers, state, etc.) Event code tables. An event code table contains an alarm panel's every code event pair. One code table can be assigned to multiple customers, but in extreme cases every customer can have its own event code table. Workflow definitions, where you can tell what tasks should the operator or the system do if a specific condition is fulfilled. Supplementary information helping customer management (comments, device information, etc.) System log. The occured events and operator interruptions are registered here. Images. An image can be assigned to multiple customers, so you don't have to store an image showing the same map section multiple times for example. Furthermore, you can also set customer specific informations for images (like zone locations, etc.) User data. System operator data and privileges are stored here. Configuration data. These are required to ensure the system's correct functioning.

Data are stored in a standard data format: The TMS uses the PostgreSQL database management system. By using standardized databases we have several external tools at our disposal to further improve the system's stability. As you can see, the database management module is a stand-alone SQL database engine, which gives us an exceptional degree of freedom in building up the monitoring system's architecture. In case of the TMS Pro, the database management system does not have to be on the same computer with the other modules, and it can also be installed on Linux operating systems to make it even more stable and faster. Because all other components connect to the database management system through TCP/IP connection you have the option to run other components on different - even physically remote - computers! 1.2 The administrator module (OrMEAdmin) Any modification regarding the system's functions can only be done with the administrator module. This module is also used for data analysis, however some of the analysis functions can also be reached from the operator module, thereby supporting the work of the operator. The module maintains connection exclusively with the database, so no other elements of the system are required for it to run properly. The module shows data for system administrators in an easy to read, object-oriented format. Data is represented in a tree structure common in Windows systems, so modifications can be easily done.
http://www.tell.hu

TMS System

General System Overview

1.3 Operator module (OrME) This module gathers data with the help of interface module(s) from the receiver units. It interprets them, shows the event if required and stores it in the database. If necessary, it starts external units or creates a workflow for the operator and monitors event handling. Furthermore, it manages state changes. The operator module's task is to present every required information for the operator in an easy to read, easy to handle form, and help him with managing the required interruptions in a fast and effective way. Apart from logged events, it is also capable of showing actual information about customers. This means the customer's actual state (Open-Close, Alarm, Technical Error status). When designing the user interface, we wanted it to be customizable for the actual needs, and that the commonly used functions can be reached in one click or key combination through different toolboxes. Different types of information are shown in different windows, which are based on a common framework. (MDI User Interface) With this module, every workflow requiring operator interruption is handled in a separate process shown in a separate window. This ensures that an operator can effectively handle multiple workflows at the same time. Later, you can easily look up and analyze these interruptions. This module's handling will be discussed in a separate chapter called "Operator basics" but of course the administrators should also know these information written here. Moreover, some functions (in connection with system configuration) can be used exclusively by the administrator! It is important that when starting the software, you can influence its functioning by setting startup parameters. This is a task for the administrator, to start the system customized to local or momentary requirements. 1.4 Interface module(s) The interface module maintains connection between the receiver (or another external device that is part of the system) and the operator module. Its primary task is to forward information between the OrME and the receiver in a uniform way. Interface modules are part of the OrME software in the form of DLL files. A good example for the system's extensibility is that by swapping the interface module, you can easily use other types or versions of receiver units. Because the OrME is capable of maintaining connections with different types of interface modules, you can easily communicate with several types of receiver modules at once. The number of receivers and interface modules is restricted by the computer's physical architecture only. Apart from receivers, interface modules are also good for communicating with other external supplementary modules. Such external modules can be:

SMS sender module, which can be used by the system to automatically send SMS notifications to specific phone number about occured (or unoccured) events based on previously defined conditions. E-Mail module, which - like the SMS sender module - is used to automatically send emails. Furthermore, the operator can manually send out emails if required.
http://www.tell.hu

TMS System

General System Overview

Dialer module, which is used by the operator to easily call (by the push of a button) a person he wants to notify about an event. This list is not complete, the system is continuously expanding with new modules to satisfy any customer needs arising.

1.5 Auxiliary tools You can assign different auxiliary modules to specific times or events received from alarm panels. These modules can be inserted into the system by modifying the database configurations. Regular data archivation in the base system is done with such auxiliary modules. A distinguished module called "DataCenter" is part of the system. This is a stand-alone software which greatly helps with data archivation and restoring procedures. When designing the TMS, it was a very important goal that in case the system unexpectedly crashes, the user must be able to rapidly and effectively restart the system with none or minimal data loss. The DataCenter is responsible for that. Further available auxuliary tools are the SetTMSParam and OrMEDataShow modules. With the SetTMSParam, you can set the parameters - like database access - required for starting and running the system. The OrMEDataShow is a "monitoring" module which can be used to look into the TMS system operator's work from a remote computer. Furthermore, you can look up customer data or log entries which enables you to effectively support your customers, taking the load off the system's operator. 1.6 Accessory tools We consider all modules accessory tools that expand the base system's functionality and help the administrator's or operator's work. These tools can be imported into the system similarly to interface modules, but their role is not maintaining connection with external systems but fulfilling specific tasks, expanding the system's functionality by becoming an organic part of the TMS. This means that you can reach and use them in specific software modules. Report generating tools are a typical example for these accessory tools. 2. System requirements In order for the TMS system to run, you require computer(s) and operating system(s) with the appropriate speed and security. Furthermore, there are some minimal personal requirements that are needed in order for the software to function at an adequate quality level. 2.1 Minimum system configuration The TMS system requires Windows XP or better, with the following minimum system requirements:

Pentium III processor 256 Mbyte RAM 100 Mbyte free disk space for the system, but the database can grow up to several hundreds of megabytes.
http://www.tell.hu

TMS System

General System Overview

SVGA display (min. resolution: 1024x768) Soundcard recommended Necessary hardware units for handling receivers (serial port, USB-Serial converter, network card, etc.) In case of TMS Pro, reliable and secure TCP/IP network connections between the computers A free USB port for the hardware key supplied with the system software

Depending on the number of customers you want to handle with the TMS system the minimum hardware requirements are subject to change. 2.2 Minimum personal requirements From the system's point of view, users are divided into two groups: operators and administrators. The operator's main task is to operate the TMS system. This requires a basic computer knowledge for managing Windows based software: using the mouse, menus, buttons, other types of controls, etc. We require a deeper understanding of computers from the system administrator. It is necessary to know the operating system's basic possibilities. The administrator should know and apply the basic operations on files and folders: create, edit, copy, move, delete. Furthermore, the administrator must understand the TMS system's architecture, its basic data connections or else he will not be able to use the system's functions to their full extent. For installing the TMS Pro system, further network knowledge is necessary, but this can be done by another person qualified if necessary.

http://www.tell.hu