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
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
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.
below shows how sensors on the same HV feeder can be used to determine
the nature of detected faults.
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
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:
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.
to be configured to only displayed status\data for selected areas.
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).
of data for external analysis by third party software.
display of action lists of PODS or system faults needing attention.
of historical archives of events.
of POD sensor parameters for uploading (individually or by groups).
of system status (e.g. phone line faults, servers off-line, etc.).
of historical archive of user logs (editing of data,
enabling/disabling of sensors, system faults, etc.).
of external alarm indicators, such as moving message display signs,
flashing beacons, etc.
Alarm Display Terminal
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
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).
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
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
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
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.