Introduction

One typical PODS system, supplied to a U.K. R.E.C, is used to provide a system to monitor HV protection equipment downstream of the points where the current HV SCADA monitoring/control system currently operates by using a series of low cost POD sensors.

The system provides:

• Indication of location of problems to a greater degree of accuracy than previously available.

• A series of monitoring terminals for staff at a number of different locations, including
  different operation/control centres, with individual terminals displaying information configured
  to a specific operators area of responsibility.

• Historical reporting facilities on collected data for fault tracing and analysis and the ability
  to automatically monitor such data and detect unusual (as defined by the user) occurrences
  such as too many recloser operations within specific periods of time.

• Multiple sensors are used for confirmation of detected faults to minimise false alarms.

• Generation of reports including Customer Minutes Lost (CML), Customer Transient
  Interruptions (CTI), Customer Permanent Interruptions (CPI), etc.

• Control of external alarm indication equipment in control rooms.

• Interfaces to third party systems.
   

The use of this system provides not only a means of monitoring the HV system in greater detail than previously possible using a relatively low cost system of sensors, but also helps to improve customer response times by being able to detect and locate faults far quicker than before.

Use of POD Sensors Within the System

The system uses multiple POD sensors at strategic points to determine when specific items of protection equipment have been
activated and to collect information for later historical analysis regarding customer minutes lost, transient interruptions, etc.

Sensors are mainly located in domestic customer's premises, and therefore are susceptible to accidental disconnection from the mains supply or local fuse problems. Reported events, therefore, are confirmed by other sensors on the same circuit.

The diagram below shows how sensors on the same HV feeder can be used to determine the nature of detected faults.

 

• A fault reported on all 5 PODs indicates that Protection Device 1 has been activated.

• A fault reported by PODs 3, 4 and 5 would indicate that Protection Device 2 had been activated.

• An individual POD reporting a fault without confirmation from any other POD from the same section of network indicates a more localised problem such as a house fuse or a local LV feeder fuse.

Host Terminal System

The diagram below shows the host terminal system, which collects the data reported by the POD sensors and presents the data
in a variety of formats to various types of users with differing interests.

The host terminal system is a client\server based system with the heart of the system consisting of a central database, in which all information regarding POD sensors is stored (network location, number of customers monitored, on board-parameters, contact information, current status, historical archives of events, etc.). The database is located on a Windows NT server and uses an industry standard RDBMS engine (this can be Oracle, Microsoft SQL Server, SyBase SQL Anywhere, etc.). The server architecture and database software allows for standard mechanisms for data security, backup and recovery which can be expanded to more fault tolerant and secure methods using off-the-shelf technology (e.g. fibre-channel storage, shadowing of the database engine including hot-swap facilities, server clusters, etc.).

Data reported from POD sensors is collected by means of two "modem server" gateway terminals. These terminals consist of a
Windows NT computer running a version of the standard host terminal client software that communicates to multiple line-modems (up to 16 on each modem server terminal) using a multi-port communications controller card. POD sensors dial a   free-phone telephone number (using the domestic customer's own PSTN connection), which is converted by the corporate telephone exchange into a hunt group of lines. The use of more than one modem server allows the system to function and collect data when one terminal is off-line.

The incoming lines are presented as a hunt-group of extensions by the customers telephone exchange in such a way that the first call is received on a line connected to a modem on one of the modem servers, the next call is presented to a modem on the other server and then next to a modem on the first server. By this method, when one server is off-line, a POD sensor may fail to make contact on its first call. When it retries, however, it is likely to be presented to the remaining modem server. The modem servers are capable of storing and forwarding data from PODs when connection to the main database is lost, such that the data will be inserted into the database when connection is resumed.

Modem servers are also configured to test phone lines by making externally looped calls using the connected modems and alerting the system supervisor to suspicious or faulty lines.

Information is presented to the users by means of a suite of client software that can display information in a way specific to an
individual user's requirements. Each type of terminal can be highly-configured to suit particular requirements.

In this system, terminals are located across a wide geographical area using the customers corporate network.

The types of client terminals in use in this system are as follows:

Standard PODS Client Terminal

This terminal is the standard host terminal software that, in some systems, is used as the sole host terminal (i.e. the PODS data
collection, database storage and user presentation/configuration are all contained within this single terminal). The terminal can be used to view current POD status, view historical archives of previous events, edit the PODs database, configure individual POD
parameters and for system configuration. Facilities can be disabled so that terminals are barred from system configuration or database editing for example. This terminal has the following features:

• Display of distribution network status as reported by POD sensors grouped by area, primary substation and HV feeder, including options to only display off-supply status for faults confirmed by more than one POD sensor or by being active for a given period of time to prevent spurious fault display.

• Ability to be configured to only displayed status\data for selected areas.

• Instant notification of special events in selected areas such as abnormal transient interruptions (i.e. more than the normal number in a given period of time), under or over voltage conditions, critical loss of supply (e.g. medical dependency customers).

• Exporting of data for external analysis by third party software.

• Automated display of action lists of PODS or system faults needing attention.

• Viewing of historical archives of events.

• System configuration.

• System database editing.

• Configuration of POD sensor parameters for uploading (individually or by groups).

• Database viewing/searching facilities.

• Display of system status (e.g. phone line faults, servers off-line, etc.).

• Display of historical archive of user logs (editing of data, enabling/disabling of sensors, system faults, etc.).

• Operation of external alarm indicators, such as moving message display signs, flashing beacons, etc.

Alarm Display Terminal

This particular client terminal is the most common within this system. It is used to present current off-supply alarm status to users in a manner more relevant to the customer than the standard PODS host terminal client.

Alarm data is presented as a list of HV feeders with detected faults. For each fault in the list, the alarm entry shows the primary substation and HV feeder, the number of PODs confirming the fault, the number of customers off supply, the date and time of the alarm and the overall status of the alarm by means of colour (acknowledged or new alarm, critical or non-critical alarm).

Selecting an entry on the list provides more details, including the details of which PODS on the feeder are reporting the fault allowing analysis of the location of the problem by means of the location of the individual sensors on the feeder.

The terminal can be configured to only display data for a specified list of areas allowing different users with particular regions of responsibility to not be informed of non-relevant alarm conditions.

External Indicator Terminal

This terminal is a variant of the Alarms Display Terminal. It provides the same facilities, but also has the ability to drive up to 16
relay contacts for connection to external indicating equipment, such as beacons and indicator boards.

Each relay output can be configured to act in a specific manner and in reaction to specific faults. This allows the terminal to be configured to activate specific indicators to denote faults detected within selected areas or to indicate system problems (e.g. modem servers off-line, loss of database connection, etc.).

Report Generation Terminal

This software is used for generating reports from the historical archive of data for network management purposes. It can generate reports of customer minutes lost, customer transient interruptions, customer permanent interruptions, etc. Reports can be tailored to a user's area of interest and saved for future generation.

System Interface Gateway

This particular system is linked to a similar system supplied by a third party by means of a System Interface Gateway terminal.
This software was specially written to monitor data on the third party system and to detect and convert data received from monitoring sensors on that system into a format compatible with the PODS system, making the sensors on the system appear to
be POD sensors.

For other systems, gateway software has been developed to provide an interface to a customers other systems, such as Trouble
Call systems, SCADA monitoring systems, etc. Interface terminals can link to other systems by database links, TCP/IP links, serial communication link or by file sharing/transfer.