MegaSys Computer Technologies - Network Management Solutions




					Telenium™ in depth
				MegaSys™ has developed one of the most powerful and flexible network management systems available. This system, designed on an intelligent, high performance object oriented database, provides unsurpassed processing power, network management and database growth. Telenium is designed to allow different network elements to be integrated into the intelligent object oriented database. Contents: Features Fault Management Configuration Management Performance Management Security Management MegaSys Telenium Distributed Architecture Inter-MegaSys Telenium Communication MegaSys Telenium Database Reports Remote Access to Network Elements Communication Methods User Interface Add-on Applications Customer Support Features - Telenium is a feature-rich system that addresses the key requirement specified. The following are some of these features/requirements: Network restoration via execution of stored restoration pre-plans that are automatically generated when a facility experiences disruption. Real-time alarm capture and continuous processing of at least 500 alarms per second and up to and exceeding 3000 alarms per second depending on the protocol and CPU configuration employed. A real-time object oriented database capable of handling 100 million points. High availability through a fault tolerant architecture. High speed display of alarms once received by the host computer. Control of alarm thresholds through software. Alarming when network element configuration controls are issued. Temporary alarm override (alarm clearing) allowed. Compliant with many industry standard communication protocols. Easy integration of new network elements. API launching of user written or Telenium written procedures or programs that can impact special functions such as predetermined control sequences, voice annunciation systems, etc. Full viewing of all network element devices including remote databases. Storage of historical data to allow for at least one year of on-line historical data at 2000 alarms per day (depending on disk space available.) Historical reports configurable by customer. Database utility programs provided. e.g. file listings, file access programs System security and data integrity provided through multiple levels of access accounts and passwords. Protection of data integrity through intelligent database design. Customer Designed Graphics back to top Fault Management - The key function of Telenium is to provide operators with a means to immediately detect network problems and "zoom" into the affected equipment to isolate and correct the problem. This function is achieved through a high resolution graphic interface to a high performance network database. The database forces immediate alarm correlation as alarms are detected. Alarm Surveillance: Network problems are discovered through alarm surveillance. The following paragraphs discuss how alarms are processed, prioritized and acknowledged by Telenium. Alarm Processing: Telenium can typically process at least 500 alarms per second continuous. Telenium normally processes and displays an alarm on the graphic displays within 2 seconds of being received by the host system. Alarm data consists of the actual conditions reported by the field equipment. As alarm data is received, it too can be written to historical files and printed. The main impact of alarm data is to affect changes in the Telenium object oriented database so that operators viewing a high level overview of the network can immediately see the impact of the specific alarm. This allows the operators to identify affected equipment and facilities and determine which customers are affected by these failures. Alarm Priorities: Telenium supports up to 64 different priorities of alarms. These priorities are assigned by the customer and override any priorities associated with protocol messages. For example, TL1 provides MJ, MN, CR and CL codes. When TL1 network elements are installed, the model associated with the equipment indicates what priority the alarm is associated with. Any or all alarm priorities can be set to generate audible alarms at the operators terminal. These alarms are adjustable for each operator to ease area of responsibility issues. Trouble ticket escalations create alarms that alert operators of outstanding ticket issues. Alarm Acknowledgment: Telenium prevents users from inadvertently acknowledging alarms before the operator has actually seen the alarm. For example, if a site is in alarm, the graphic may indicate a red blinking circle. Pressing acknowledge alarm on this circle will not acknowledge alarm since the operator has not actually seen the root cause of the site alarm. The operator is required to either "zoom" into the site to view the alarms, or press the "alarm list" key and acknowledge the specific alarm list for that site. This feature prevents accidental acknowledgment of critical alarms such as fire, security or major traffic affecting. An operator can choose to override an alarm by either forcing the point normal, disabling the alarm condition short term, or disabling the alarm long term. In all cases, reports are provided which show all points in the system that have been affected in any or all of these manners. Alarm points resulting from messages that cannot be normalized are automatically cleared when acknowledged. Fault Isolation: Telenium supports full alarm processing and in all cases the database performs all relational aspects automatically. This provides a "root" causes and helps to isolate faults quickly and effectively. User can request fault locating data from network graphics or this data can be automatically issued at preconfigured time intervals. Thresholds such as rate of change alarms are provided by Telenium to facilitate fault locating. Alarm Relationships: Telenium provides for full network management by utilizing a powerful database in a network topology orientation. Because of the built-in intelligence of the database, relationships between database elements are fully managed by the database. This allows for a topological representation of the customer network. Telenium classifies alarms into a number of user defined categories. Typically these categories include: Telemetry - Alarms that impact telemetry processing; alarms indicating failure to communicate to a network element. Environmental - Alarms impacting the physical sites, such as temperature, power, fire, etc. Traffic - Alarms that impact the traffic carrying ability of the network. Most alarms are in this class. Equipment - Alarms that affect NEs such as power supplies. Each of these four primary classes provide for database relationships so that operators need not simply read and interpret text, but can instead understand the impact of the alarm through geographical and statistical graphic displays. For example, a traffic alarm at its lowest level does not indicate to the operator which physical equipment reported the alarm, nor does it indicate the channel section (regen. to regen.) or channel segment (terminal to terminal) or route segment. The Telenium database maintains all of these relationships so that the operator immediately understands the impact of the alarm. Data validation is integral to Telenium and is performed by the database itself. The database incorporates those fields from the network element protocol message that apply to the target record. Date and time stamps, if included in the protocol message, are extracted and used as the time associated with the value. All complex algorithms are inherent in Telenium database design as described by the database relationships above. Thus, even complex performance monitoring and fault locating parameters that may require reference to vendor specific parameters can easily be processed by the database without extensive operator setup. Other critical relationships are automatically assumed by determining where the message originated from. The telemetry path of the Telenium database defines the type of equipment connected to the remote end of the port. Thus, a particular type of equipment and particular manufacturer can be defined by the database to again indicate to the operator how the impact of the alarm affects the entire network. API Launching: Telenium allows alarms to launch user written or Telenium written procedures or programs. These procedures can then impact special functions such as predetermined control sequences, voice annunciation systems, etc. Telenium allows full application launching from its graphical interface. This includes activating any MegaSys application, user application or operating system level application. Standard applications such as FTAM for loading network element configurations are also available. Trouble Tickets: Telenium comes complete with an integrated trouble ticket package. This package allows operators to associate alarms with a particular ticket and incorporate fundamental features such as four level alarm escalation, SQL based ticketing, customer associations, etc. Full reporting of open and closed tickets is provided. Alarm Archiving: All alarms detected and/or generated by Telenium are archived into permanent historical database files. Extensive information is written with the alarm data itself to cross-reference the alarm against geographical sites, network topology impact and physical attributes. If configured with synchronized processors, all synchronized processors contain identical copies of historical data. Therefore, even if a processor fails with a hard disk failure, historical data on other synchronized processors continues without interruption. back to top Configuration Management - Telenium can manage network elements from many different management locations. Network elements can be configured remotely through a point-and-click interface. Reach through capabilities are supported over X.25, LAT, DECnet, and TCP/IP through V.35 and V.24 interfaces. Standard applications such as FTAM for loading network element configurations are also available. This enables rapid disaster recovery. The database can be populated with the network equipment definition using the autodiscover utility. Provisioning: Telenium supports provisioning of network elements in a user friendly manner. The provisioning of shelf cards, shelves, network elements, terminations, etc. within a network element can be configured and provisioned in or out of service without requiring that the NMS user have knowledge of the network element native protocol (e.g. TL1, PDS, etc.). Similarly the parameters and attributes associated with network element equipment can be set and changed without requiring the user to have any knowledge of the network element protocol or communications language. Finally, cross connections can be created or destroyed entirely via a graphic user interface. back to top Performance Management - Telenium provides real-time graphical display of network element performance statistics. The most recent 120 values of performance monitoring data are maintained in the real-time database for immediate trend analysis. Performance monitoring data can also be historically archived to allow trending for long-term analysis. Users can design performance trends with the graphics editor (GED) for monitoring bit error rates and other performance thresholds. All performance thresholds are user-definable through Telenium. Parameters such as BER, BBER, EFS, and switched events are calculated based on vendor specific tables. The Telenium database relates specific network elements to vendor records which are required to accurately perform these calculations. back to top Security Management - Telenium provides full security control for access to the workstation operating system functions and the MegaSys database. The following paragraphs describe these security measures: Operating System: The host operating system requires both a valid user account and Security password. Password lengths can be specified to ensure easily guessed passwords cannot be chosen. Likewise, password expiration periods can be set forcing users to change their passwords periodically. Passwords: Passwords within Telenium are one-way encrypted to ensure that data dumps will not reveal password information. Passwords need not be only digits; they can be any alphabetic keys, numeric keys, "$", "_". Up to 32 characters can be entered which allows for much greater security. Logon: Logon attempts are recorded in a system trace file and show the date, time and attempted user name that failed. Successful access to the system is recorded in the accounting file which shows the number of successful logins and the date and time of the last successful login. User Access: Access to Telenium is governed by logon access that allows users to have one or more of eight total categories. The categories of users can be totally reconfigured for each customer's use. The following categories are provided by Telenium: Training Alarm Block System Administrator System Configurator System Operator Customer Assigned Customer Assigned The user name is recorded and maintained on the top of the graphic station screen. Any appropriately tagged events generated by that operator are tagged with the operator's name and archived to history. The historical extraction report program can subsequently extract those records as audit reports tied to a specific user for post analysis of operator reaction. These privilege categories are not hierarchical. For example, a system manager who can create new accounts or add new database records can be restricted from performing operator functions such as acknowledging alarms or issuing controls. Also, database configuration personnel need the ability to add new database records but should not be allowed to acknowledge alarms. Operators, on the other hand, need to acknowledge alarms but should not be adding records to the database, or creating new accounts. Database Security: The Telenium database itself also requires account and password access beyond that provided by the operation system. The Telenium database requires account and passwords before granting any type of access to the database system. Failure to enter a valid database account and password prevents both read and write access to the database being referenced to the user. Database Access: The DBM (DataBase Manager) program allows full database access. Modification rights are available only to specific database fields based on the user's login privileges. Actual field protection schemes can be set up or modified at any time by personnel with the appropriate privileges. The functionality and capability of this program is detailed in the DBM User Manual available from MegaSys. All reads and writes (query and update) are supported by the systems; however, access is always restricted by the user's privileges to assure database integrity. Telenium database does not allow programs direct access to the database records. Instead, programs must queue requests to the database. The database can then check the legality of the program, assuring that the reader/writer has been granted sufficient privileges, and that the data being written is valid for the type of field being impacted. Database Modifications: The DBM program provides full database management in a simple screen oriented utility. System integrity is maintained by the database by the following protection schemes: Each user is assigned certain privileges. Each database element or field is protected from classes of users. Only those users granted one or more of the required classes can modify the specific database field. This applies not only to DBM, but also to any program the user attempts to run. Users may be granted "Read-Only" access if they are restricted from modifying any aspects of the database. Database modifications can be tracked so that a post analysis of the modified field can be viewed. For those fields where modification tracking is enabled, a historical data entry is entered and is time stamped along with the user's name. Regardless of how the database is modified, either through graphics, a PC, or a user written program, tracing of the modified fields can be tagged with the user's name. The flexibility of Telenium allows customers to set up all modification criteria and restrictions. Wide Area Network: If a distributed architecture environment is employed (described below), or access to/from cooperating corporations is granted, remote users must name an account and password on the targeted processor that match the account and password on the local node. These accounts are controlled by the servicing system, thus the local system administrator controls which remote users can access their database and vice versa thereby assuring that users on remote computers do not attempt unauthorized access to alarms or controls beyond their intended scope. A dual level of protection is available to all system users that helps to accurately manage remote users' access scope. Remote users may be granted viewing access to many alarm categories but perhaps only write access to a subset of those categories. This functionality is standard on MegaSys systems. Remote users may also be allowed to affect appropriately tagged events. Even though these users are remote from the primary Telenium control system, any events generated by them include their individual names. back to top MegaSys Telenium Distributed Architecture - Telenium offers a powerful and flexible distributed network configuration that maintains system integrity and redundancy by providing a robust parallel processing architecture. For small networks Telenium can be deployed as a single processor system; however, such an architecture does not provide the performance and reliability of redundant, multiprocessor architectures described below. Synchronization: An exceptional feature of Telenium is that it allows more than one computer to be tightly synchronized for load distribution and request servicing. Unlike typical "hot/standby" configurations, Telenium synchronizes all cooperating computers typically to within 5 milliseconds of each other. This synchronization is maintained constantly so that all cooperating computers accurately reflect each other. Synchronized processors offer the ability to transfer primary control between processors without having to bring a "standby" processor up to speed. Telenium maintains such tight synchronization between processors, that swinging mastership between synchronized processors is virtually transparent to the user community. Synchronization can be maintained over both local area (LAN) and wide area (WAN) environments. In a wide area network (WAN) synchronization configuration, local nodes are still synchronized typically to within 5 milliseconds of each other; however, computers remote from the primary control center are "WAN" synchronized. These remote processors are synchronized to within 1 or 2 seconds of the prime control center. WAN synchronization allows remote computers to take over in case of catastrophic failure of the prime center. Failure Response: Any type of hardware failure causing a processor to fail does not impact the ability of the remaining processors to assume the processing load of the lost node; these remaining processors continue without interruption. The other computer(s) which are tightly synchronized to the lost node typically contain data not more than 5 milliseconds older from the logical network master. There is no need to refresh data files, read current alarm conditions from the field or attempt to reconstruct historical data. All this information is maintained by the synchronization aspect of Telenium. A processor that has been disconnected from the network such as in the case of preventative maintenance or system failure, automatically detects and re-synchronizes with its designated database, once it is reconnected to the network. Re-synchronization is completely transparent to system operators. In instances where a processor(s) is unavailable, any graphic station can be reconnected to the remaining active processors, even if they are not within the local network. Since Telenium provides for Remote System control, in the case where the primary control site may have to be evacuated, either alternate customer personnel or appropriately trained backup personnel could continue with full system operation from any secondary or distributed control site. Request Servicing: Since all computers are effectively identical, servicing of data requests by graphic stations, other remote nodes, historical analysis, etc. can be serviced by any of the synchronized processors. This lessens the requirement for large host computers which need to service all database requests. back to top Inter-MegaSys Telenium Communication - Communications between all of the active MegaSys network management systems is critical to ensure that the user community has full visibility of the communications network. Data transferred between these systems must meet integrity concerns; therefore proper cyclic redundancy checks (CRC) must be incorporated. Because of the transport intended for use, CRC checking is implicit. Primary Data Transfer: Communications between MegaSys network management system Path devices use the 802.3 Ethernet protocol. The communication layer used between these processors runs concurrently with TCP/IP and DECnet for higher level protocol interchange. Seven layer OSI compliant communication protocols are supported. Ethernet 802.3 runs at 10 million bits per second. Connection between geographically distinct MegaSys systems typically do not have the bandwidth available to maintain this speed and thus wide area network (WAN) bridges are used. These bridges should provide 256K baud optimally and a minimum of 56K baud between nodes and must support routing capability to bypass circuit breaks. Wide area networks connected by bridges, routers, LAN switches and/or gateways are all supported. ISDN, frame relay, HDLC and other circuit types are also supported at speeds from 56K to FDDI (100Mbit) with support for DS0, T1, DS3, ATM and other interfaces. Third party equipment such as Applied Innovations and Cisco are also supported. Depending on the customer's standard preferences, a number of compliant bridge/routers are available including Applied Innovations and Cisco. Brouters based on the Cisco protocol suite are well accepted and functional. Brouters purchased from MegaSys are configured by MegaSys and are guaranteed to function with Telenium. Tertiary Data Transfer: In case of failure of the extended Ethernet, the selected brouters should be capable of either automatically or manually initiating a dial-around to restore the WAN. ISDN circuits can provide a very cost effective and high-throughput service and should be considered. Depending on the brouter selected, Telenium can provide manual control of the unit by having an operator activate a task trigger on any of the graphic stations. All site locations are also configured with security dial-back modems. This allows users anywhere in the network to "dial" into a MegaSys Telenium. The modem prompts for a password and dials back to the associated phone number, assuring only authorized users from authorized locations can access the system. Once connected, users can view and control the network. back to top MegaSys Telenium Database - Telenium is built around an intelligent, high performance object oriented database. Database Design: Telenium database design is inherently object oriented and designed to allow different network elements to be integrated into the database. Database constructs and object relationships are co-designed by customers and MegaSys to ensure that the most effective architecture evolves. Telenium allows full database modification, addition and sizing on-line. All changes take effect immediately and all graphic frames immediately display the new information. Data changes that need to be recorded to disk are done immediately upon detection, not at some cyclic period. Remote data is also immediately impacted, thus if a new network element is added into the system, communication with that network element starts automatically and data is inserted directly into the database. Users can write their own custom applications and access the database through a published API. As with all applications, user written applications will have database privileges that correspond to the user's account. Database Functions: The prime database management tool (DBM) is a visual screen oriented program. This utility can also be used for database validation and executing "learn" sequences to aid in database population. Telenium is fully configurable on-line. Not only can the database be updated, it can be resized on-line. Authorized personnel can add new records to the database while the entire system continues to process alarms and service graphic stations. All synchronized processors track the changes exactly to ensure that absolute synchronization is maintained. Telenium provides extensive relationships between the objects demanding that alarms be related to circuit objects, card objects, shelf objects, etc. Users can configure their own links as necessary to incorporate geographical links. The primary session manager screen associated with each user is customizable by the database. Functions such as backing up the system, invoking MegaSys or user written programs, etc., can be completely customized on-line. Adding new features and functionality to the system seldom requires a reboot of the system thus assuring a highly available system. Telenium database is fully configurable by the user. The objects support certain attributes that system configurators can affect such as privilege of user required to modify each specific field in the object, whether modifications to any or all fields are traced in the historical files, etc. All database access, via either graphic stations or local a PC is processed concurrently with the system. Both reads and writes (query and update) are supported by the systems. The database may be modified, either through graphics, a PC or a user written program. A PC can access any node in Telenium wide area network. These terminals can be used for database manipulation or system checking. Dial-in access can also be accomplished through on-site modems which are in turn connected to an on-site terminal server. Typical terminal servers can be configured to demand passwords before granting access to the node. In addition, terminal servers can automatically connect to a specific host to ensure that the user does not attempt to access non-authorized computers via the wide area network. All programs used to build graphics, display graphics, build database, incorporate new programs, etc., are available on any of Telenium stations. The only restriction is that the operator must have proper authorization to perform these functions. This authorization is assigned by the system administrator on-line as accounts are added or modified. Database Utilities: Utility programs provided with Telenium include database management programs, data file dump programs, command line database access programs, etc. Operators, granted sufficient privilege, have the ability to backup and restore databases, historical data, graphic frames, and perform data dumps and disk usage checks. New requirements can be easily added to this menu driven process without the direct intervention of MegaSys. back to top Reports - Telenium provides for a number of reports including standing alarms, historical alarm frequencies, database modification traces, security breach attempts, etc. Historical data produced by Telenium is stored in a standard file or SQL form and can easily be accessed, if required, by the customer's own software for post analysis. MegaSys does provide a full historical data extraction tool that utilizes a GUI X/Motif interface which allows the user to specify which criteria are to be considered when generating the report. Any criteria matching is allowed. Historical data extraction and analysis tools provided with Telenium provide access and reporting abilities from the historical files. MegaSys provides a number of standard reports with Telenium. Included in these reports are the following: Historical Extraction by Criteria. Since the customer can indicate which information is to be stored historically when an alarm occurs, the historical reporting allows the users to specify criteria for inclusion in the report. MegaSys provides a powerful historical report program using a user friendly GUI for selecting the match criteria and the time spans. Current standing alarms (system wide or by specific sites or other database records). Alarms affecting any object in the system are immediately available from the real-time database. Current communications statistics for each of the communication drivers. Current system status reports showing overridden alarms, forced points, long term and short term disabled alarms, etc. Graphical screen printing in color or black and white on compatible printers. Operating system level reports for security breaches, break-in attempts, network activity, etc. are also available. Many other reports are also included and MegaSys can develop additional reports as deemed necessary. Historical Data Access: Programs are provided to allow an operator to request a historical report derived from data stored in the historical files on the host system. Criteria specifications allow the operator to limit the report output to a qualifying subset of the historical data if desired. Criteria include network element name, specific alarm point, date range of historical data, state of point, etc. Any data in the database can be included in the history and is fully configurable by system configurators. The results of the request can be targeted to either the user's own terminal or to the assigned print spooler. Typically the print spooler is a local hard-copy printer at the computer site but it could be any printer in the network. back to top Remote Access to Network Elements - Remote access to network elements can be provided in two ways: A field technician can use a PC to tie into a free port on the terminal server. From this connection, he/she can create a logical connection to any network element either locally or at a remote location (security issues can be incorporated to limit access). The resulting logical connection allows the technician to communicate to the network element in the native mode of the network element (i.e.: PDS, TL1, etc.). A field technician can use a PC with X emulation software or an X station, and connect to Telenium via either a free port on the terminal server or the Ethernet LAN at the site. This type of access will provide the technician the same interface as Telenium operator station has although somewhat slower due to the wide area network bandwidth. It should be noted that with the addition of a modem, a technician could also dial into the system, and via a PC or X station emulation software, perform monitoring and control functions. back to top Communication Methods - Two primary communication approaches exist for collecting information from network elements: polling and autonomous. The protocol approach implemented depends completely on the network element and the characteristics of the protocol. Autonomous: Autonomous protocols such as TL1 and DMS switch messages are generated as needed by the network element. Telenium does not need to poll the remote network elements for this information, and in some cases, cannot issue commands to receive this data at all. For those protocols that support OS commands, such as TL1 and PDS, Telenium automatically requests lists of standing alarms as required to check for alarm integrity. TL1, one of the most common protocols used in newer network elements, also provides for alarm sequencing. Upon detection of communication failure, alarm missing, or a sequence out of order, Telenium automatically performs a full upload of all standing alarms to again ensure database integrity. TL1 also supports remote logon and logoff. This functionality is inherent in Telenium TL1 interface software thereby allowing a reboot of the network element which subsequently causes an automatic reconnection and re-logon from Telenium without operator intervention. Telenium also supports concurrent communications to one or more network elements via the same gateway, thereby allowing controls to be issued even though the system may be uploading alarms from a different network element. Polling: Low level protocols such as DCPS, BADGER, etc., typically require polling to read alarms. Telenium polls the network element at a user defined frequency and processes the resultant data. In protocols where alarms are reported by exception, Telenium periodically requests a full upload to assure database integrity with the remote network element. Communication failures or other errors force an immediate request for a full upload. Polling protocols typically allow operators to request a poll of a specific RTU out of sequence. Fast scans, which interleave the polling of a specific RTU to the standard polling sequence, are also supported. Operator commands are processed at the first opportunity, regardless of the currently polling sequence. Polling typically occurs at about 2 sites per second, based on the performance capability of the remote monitoring units and the number of data bytes for the communication handshake. Statistics: All communication drivers maintain statistics within the database for Statistics ongoing analysis of communication reliability. Since the statistics are maintained by the database, operators can view the statistics in real-time by activating the appropriate graphic display. At minimum, the following statistics are maintained for each network element connected to Telenium system: Number of communication attempts. Number of successful communication attempts. Number of failed communication attempts caused by no response time-outs. Number of failed communication attempts caused by receipt of a bad data integrity (BCH, CRC, Checksum) character. Number of failed communication attempts caused by receipt of an incorrectly formatted data byte (frame error, overrun error, or parity error). For those network elements that require polling, statistics are typically reset on a periodic basis to prevent overflow and provide meaningful daily trends. If desired, a copy can be printed on the local printer before being reset. back to top User Interface - Telenium provides both a graphic and non-graphic user interface. The following paragraphs describe these: Graphic User Interface: Telenium is very user friendly. It uses a high resolution GUI; the operator never has to deal with operating system level commands. Telenium Graphic Stations are high resolution (1280x1024) color displays which provide the primary man-machine interface. Any data available from the database, including text, numeric data, alphanumeric data, algorithms, or any other data available in a textual format can be displayed on the graphic stations. Display Functions: Operators simply use either keyboard commands or the provided mouse (optional trackball) for selecting points, bringing up new displays and zooming into or out of the relational hierarchies. Users place the cursor on a dynamic point and activate it with the press of a mouse or trackball key. A new graphic is then displayed with more discrete database information relating to the point. The graphic stations provide full historical and current data trending. A maximum of 8 pens can be trended in any single trend with up to 10 trends displayed in a single frame. As mentioned previously, any number of X/Motif windows can be displayed, each containing up to 10 trends of 8 pens each. Graphic Creation: The graphic oriented stations can display custom built graphic frames easily by utilizing the Graphic Editor (GED) program supplied with the system. This easy to use "PC Paint" style package allow users to very quickly build sophisticated graphical displays. The graphics are easy to build not only because of the user friendliness of the GED program, but because of the intelligent object oriented database, graphics don't need to develop complex derivation for color and state. Full graphic capability exists on these stations. Since the screen is a true graphic display, all types of graphic primitives are supported, including: lines, poly-lines, polygons, sectors, circles, rectangles, font text, stroke text, text at any baseline angle, etc. Attributes such as filled, thickness, etc., are also supported. Text size can be adjusted to any size. All graphic primitives can be drawn in any static color or have their color derived by Telenium database. Likewise, static text can be entered or text contained within the database can be extracted. Text, like any other graphic primitive, can be colored a static or dynamic color. The database also assures consistency for all graphics. For example, when color is extracted from the database for a particular point, all extractions from the database for similar points (those in the same category) return the same color tables based on the points status. This eliminates the possibility of users developing graphics inconsistent with each other. Windows: These graphic stations provide a high speed X/Motif windowing system capable of displaying multiple colors in multiple windows simultaneously (virtually any number of windows). In addition, standard PC style windows can be requested to allow connection to standard serial devices such as network elements, modems, printers, etc. Each window can reference data from any database in the network managed by Telenium, regardless of whether the database is local or remote over a wide area network. In addition, each primary window can be assigned a default MegaSys Telenium database and an area of responsibility. Any windows generated from this primary frame take on the same attributes as the primary frame. The entire windowing, default database and area of responsibility feature provides not only tremendous flexibility, but allows system administrators to construct an information scope specific to their requirements. Non-Graphical User: The non-graphic interface provides access to the host computers via Interface direct connect or dial-in PCs using terminal emulation software. Any display terminal in the wide area network can access Telenium and, after logging in to the system with an appropriate account and password, can evaluate, and granted sufficient privilege, manipulate Telenium database. back to top Add-on Applications - The following applications are available enhancements: Network Restoration: Network restoration is achieved via the generation of dynamic pre-plans. In essence, alternate routing is calculated for circuits at the time that a facility failure occurs. In such an instance, restoration is accomplished by re-routing facilities starting with the failed facility and progressing to constituent facilities in priority order. Obviously, there is no guarantee that complete restoration will occur depending upon available spare bandwidth. Under no circumstances is live traffic disrupted for the purposes of achieving restoration after a facility failure, and facilities will not be disconnected if an alternate path is not available. In addition to dynamic restoration, the user can manually enter pre-plans which are then associated with a facility. If such a pre-plan is available, then its use will supersede dynamic restoration in the event of a facility failure. In either dynamic or pre-plan restoration strategy, Telenium can automatically initiate the restoration sequence. This is achieved by defining a "derive" function which is associated with 1 or more alarm points affected by a facility failure. All database constructs and associated data relating to pre-plans and other automatic command sequences are entered on-line by the operator and/or system configurator. Adding new network elements, new pre-plans, new routes, etc., does not require any involvement from MegaSys. Obviously appropriate training is paramount to a successful installation and management of the system by the customer. Circuit Management: Telenium permits the user to provision new circuits by simply specifying the A and Z points associated with the circuit. Telenium also supports manual assignment. The circuit provisioning algorithms within the NMS will automatically locate routing options maximizing either diversity or utilization. If no spare bandwidth exists to provide for the circuit, then the user is informed of the situation. In all cases, the user is given the opportunity to review the proposed routing and if accepted, Telenium will attempt to invoke the new circuit by issuing appropriate cross connection commands. Telenium supports circuit synchronization with the network to provide for the installation of Telenium into an existing network. Future releases will support recovery from a major network failure, such as the loss of a digital cross-connect system. back to top Customer Support - MegaSys offers a 24-hour extended support hot-line contract which not only provides for expert technical aid, but also provides software updates at no additional charge. Training: MegaSys offers numerous training classes covering operator training, database management, graphic frame development, etc. These training courses can be provided either at MegaSys offices or at the customer's site. Users can receive numerous levels of training, from floor operator to system administrator, system configurator, graphic generation, etc. Documentation: MegaSys provides an extensive documentation set with every Telenium purchased. Telenium is provided with a full on-line manual set accessible via the graphic workstations. Programs such as the database manager program (DBM) have built in help screens and prompts. Graphic programs can bring up help windows as designed and drawn by the operators. All documentation for Telenium and the operating system is available in both hard copy and on-line. back to top