Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / Languages / Java / JavaSE

Remote Monitoring of Terminal Exchanges: Microsoft .NET & Java – Part 1

3.50/5 (11 votes)
16 Aug 20057 min read 1  
This article discusses the Terminal Exchange and Remote Monitoring terminology and the use of the latter in Terminal Exchange.

Summary

This article discusses the Terminal Exchange and Remote Monitoring terminology and the use of the latter in Terminal Exchange. This is part one of the two series article. The part one of this article provides an overview of the Telecom terminal exchanges and Remote Monitoring. The part two of this article examines various technologies under Microsoft .NET and Java which can be used for implementation. This part 1 gives an overview on the advantages of remote monitoring and presents a scenario of how the remote monitoring works for Terminal Exchange and what its benefits are.

What is a Terminal Exchange?

Terminal Exchange is something like a switchboard which acts like the heart of the telecommunication system. It is the central system of the switches and telephone lines and acts as a connector between different telephone lines. To get a better understanding of the Terminal Exchange, we can consider it as a large scale central computer used to route calls to different telephone lines.

Based on the manufacturer, these terminal exchanges have various ports. Hence the number of lines which can be connected to a terminal exchange is dependent on the type of the terminal exchange (basically the manufacturer). So, now the whole point of the number of terminal exchanges boils down to the density of telephone lines in an area. Various factors rule the type and number of terminal exchanges to be placed at a location. It may range from a few tens to hundreds of exchanges at each station/sub-station.

What is Remote Monitoring?

In this fast paced world, everyone wants everything to happen at the click of a button. Almost all the organizations are trying to move out of the traditional processes to more scientific processes. This transition includes elimination of most of the manual processes to get more accurate results and get the job done in a more efficient manner.

If we go one step ahead, all the time critical operations are now monitored remotely unlike the old idiom of having a person placed at the site to monitor regularly, which leaves for a possibility of more errors.

So, Remote Monitoring is nothing but the ability to monitor a process from a remote location. The next step to this can be controlling the process along with monitoring from a remote location. We can have a central database at the remote location to log the process details and to store the appropriate commands for controlling the process based on the condition received. This can be achieved by HMI (Human Machine Interface) or MMI (Man Machine Interface), which is a series of interactive commands, bundled up into a GUI package which can be understood by the machine. The communication between the local unit and the remote location unit can be achieved through different communication mechanisms like cable modem, wireless, etc., based on the location and the cost factor involved. Refer to figure 1 for a basic unit of a remote monitoring system.

Image 1

Fig. 1: Basic Block Diagram of a Remote Monitoring Unit

Why do we need Remote Monitoring?

Now, coming to the topic of why we need a monitoring system for the Terminal Exchange. Irrespective of the number of exchanges, its type, manufacturer of a terminal exchange, all these exchanges require a considerable amount of maintenance. And there are several critical factors like temperature, earth resistance, voltage of main and backup battery, etc., which have to be monitored on a regular basis for the smooth functioning of the terminal exchanges. The manual process for this can really be tedious at times because of various environmental factors as these terminal exchanges are usually located at remote locations. Looking at all the above factors, human error is more likely at such situations.

To overcome these difficulties, remote monitoring through a supported HMI provides optimum solution with more efficient monitoring at an overall less cost. It helps to store the data at the central server as usually these exchanges have comparatively less memory. This helps to retain the data which can be very helpful at times of debugging an erroneous condition.

Sometimes, for very small jobs like changing the critical parameter limit, an engineer has to go to the remote site, which can be a huge overhead both cost and time wise. By having a HMI controlling system, the parameters can be changed remotely.

Design of Remote Monitoring of Critical Parameters in Terminal Exchange

System:

Central Server:

  1. Desktop with the HMI
  2. Database
  3. Modem connection to PSTN
  4. Wireless connectivity and software to send SMS
  5. Buzzer connected to the desktop (internal buzzer)

Remote Unit:

  1. Modem connectivity
  2. Serial port for one time configuration of the parameters
  3. Buzzer

Working:

Central Server:

  • Central server can act both like a receiver and sender. It can be programmed to send heart beat commands periodically to all the remote clients it is connected to, to check if they are alive or not.
  • At periodic intervals, the server will request data from the clients. In case the client does not respond, it will try thrice and still if the client does not respond, the server proceeds to the next client and returns back to the failed client. This whole process is based on a round robin fashion. The number of retries and the interval to ping the client for data is user configurable.
  • When the server is in the receiving mode, if it receives any alarm message, the server immediately raises the buzzer and simultaneously sends an SMS message to the configured numbers. In case of failure to send the message, based on the user configuration, the system will try the backup number. The number of retries is also user configurable.
  • Show the data to the user as it is received and then store the received data in the database with time stamp and client header information to differentiate between different clients.
  • Send the data to the backup server in case the main server is down.
  • Allocated dedicated PSTN line to receive and send messages.

Remote Client:

  • Before turning on the client device, configure the client through serial port. The configurable parameters are:
    1. Maximum and minimum values for the critical parameters.
    2. Number of times the buzzer has to rise in case any of the monitoring parameters are not in the specified range or any of the batteries under monitoring is down.
    3. Number of retries in case the client fails to send the data to the server.
    4. Fallback process if problem not rectified within the specified time period after raising the alarm.
    5. Server address (number to be called) to be contacted.
  • Once configured, based on the parameters, at regular intervals the client sends data to the server.
  • Under failure condition, the failure message is given priority to be sent to the server over ordinary data.

Block Diagram

Image 2

Fig. 2: Block diagram of the above discussed scenario

Advantages

  1. Remote monitoring system does not interfere with the ordinary working of the terminal exchange.
  2. Obvious advantage of remote operation of the cluster of terminal exchanges.
  3. Undoubtedly overcome the human errors.
  4. Considerable reduction in labor costs.
  5. Capture the information with no loss of data due to insufficient capacity at the terminal exchange.
  6. Scalable, and the communication medium can be upgraded to wireless from PSTN.
  7. On demand dispatch of engineers is very cost effective and many more advantages.

Conclusion

In this article, we have discussed in brief the advantages of remotely monitoring the terminal exchanges of a telecommunication system. Lot of work is progressing in this direction from various departments. What we have presented here is a synopsis of what can be achieved by remote monitoring. It does not cover in depth in terms of deployment. There is an ongoing work going on in this direction. Be tuned to get the latest updates in this technology. In the next article, we will discuss about various implementation options under Microsoft .NET & Java.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here