- Email: [email protected]
AUSTRAL, A Multi-Platform System for Alarm Processing and Decision Support System for Distribution Network Operation
AUSTRAL, A MULTI-PLATFORM SYSTEM FOR ALARM PROCESSING AND DECISION SUPPORT SYSTEM FOR DISTRIBUTION NETWORK OPERATION Jean-Paul Krivine and Olivier Jehl
Electricite de France Research and Development Division, Power System Department 1, avenue du General De Gaulle - 92140 Clamart - France Telephone: (+ 33) 147654321 - E-Mail :. @edfgdffr
Abstract: To improve distribution network efficiency, EDF is developing AUSTRAL, a package of real-time functions for alarm processing, diagnosis and service restoration. AUS1RAL will become operational at the beginning of 1998 in three French control centers (Lyon, Nimes and Versailles). The main aim of the AUSTRAL system is to cut overall outage time. AUSTRAL is a fully integrated system that shares data and MM! (Man-Machine Interface) with the telecontrol system (SCADA). It operates directly on real time data. AUSTRAL is a multi-platform package that may run on several telecontrol systems. The connexion is made via an explicit interface (AP.I. for Application Program Interface) provided as part of the basic SCADA Copyright© 1998 IFAC Keywords : Distribution Network, Alarm processing, Power restoration, Expert systems, Connection to SCADA, Application Program Interface (API).
found to be de-energised, Figure 1 shows the general feedback loop linking the AUSTRAL functions.
1. INTRODUCTION To increase telecontrol efficiency, EDF's Research and Development Division is developing a set of advanced functions operating on real-time data supplied from a SCADA. The main objective is to reduce the overall · outage time. This goal will be achieved using two kinds of functions. The first one aims at increasing the understanding of operators of what is happening on the network. The Event Synthesis Function (ESF) will reduce the number of events displayed in the General SUIIl1IlaIY. A diagnosis task is also performed and will provide an explanation of the cause of main outages. The second set of functions aims at proposing actions to be carried out for solving some identified problems. The main function developed for this purpose in AUSTRAL is the NRF function (Network Restoration Function) which is invoked when part of the network is
The AUSTRAL functions operate directly on real time data. They input actual incoming remote signals and remote measurements, supplied by the telecontrol system via a standardised interface. The main objective is to deliver advanced functions to operators that are strongly integrated to the basic SCADA The AUSTRAL functions described in this section share the telecontrol system MM! and then present a quite unified look and feel. In the same way, there is no specific database for AUSTRAL. AUSTRAL uses the data stored in the common database. AUS1RAL doesn't need any specific data administration system.
485
The first operational version of the AUSTRAL is scheduled for delivery at three French centers (Lyon, Versailles and Nimes) at the beginning of 1998.
l~~~~~s~oss.Y.OSSS.~··~··~··r~~·s·~·~~~~i
i Type of reglOn ~ :r--.-
l
nuxed rural / ! urban
~ Number of customers
®I':;~~I
i
.---.....:;..,...--.-----~§
~
I I:::----
l 4000 GWh
i 700 l
Overhead lines
~
Cables
Number of substation Number of feeders
"
.
~ Dlsconne~J~~E.~eder ~
I~
Figure 1 : Functional overview
Remote controlled disconnectors Eer feeder
~ Fault detectors per feeder
~
This paper presents a full description of the AUSTRAL system. Section 2 starts with a brief description of the French distnbution networks, and sumarize the current state of the project. Section 3 provides an in-depth description of the main AUSTRAL functions (NRF, FL and ESF). Section 4 discusses the hook-up to the telecontrol system.
~
km
~ ~
I
l 2700 km
~
I 18 l; 275
~
l.
~
l~ 3 (remote
~
.;..-~----~ ~ ~
~
I
8§5 000
,~
~ En~~ consS!tion Eer ~ear ~
®[email protected];;Q
~ ~
oeec:eeoeo::eceeoc:o
~
~
1 10i~~-J ~ 1 3 (in average) ~ ! ~
ce::e:e::el:e:~::~~~l~)
~
:oee=~
Figure 2 : Characteristics of a pilot site for AUSTRAL
3. DESCRIPTION OF THE AUSTRAL FUNCTIONS AUSTRAL is composed of several functions directly connected to real-time data. They are automatically triggered according to network events and results of previously activated functions. For instance, power restoration (NRF) should be triggered after the Event Synthesis Function has recognised a specific diagnosis and FL has localized the fault. Some important synchronisation between functions taking care of the network state is needed. A module, called Supervisor, is responsible for this task and manages the links to be established and the functions to be launched in each situation.
2. THE EDF DISTRIBUTION SYSTEM AND THE AUSTRAL SYSTEM EDF Medium Voltage (MV) distribution systems mainly operate at 20 kV. They are supplied by 63/20 kV, 90/20 kV and (occasionally) 220/20 kV substations. MV networks operate in a radial configuration but have a meshable structure. A MV feeder comprises about f"Ifty switching devices on average (located in the LV substations on underground networks or pole-mounted on overhead feeders) . Most of them are locally (i.e. manually) controlled. However a few elements (two or three per feeder on average) are remote controlled; these are generally located on the frames. Fault current detection devices, which indicate whether the failure has occurred downstream on the feeder, may be associated with the switching elements on both overhead and underground networks. Those associated with remote controlled elements are usually remote indicated. Figure 2 shows the characteristics of one of the control center that will host AUSTRAL in 1997.
The main AUSTRAL functions are the following:
The AUSTRAL project started in 1993 . Mter a successful prototyping of the power restoration function (Bredillet, et aL 1994), an industrial phase began in 1994. A preliminary off-line version has been delivered for experimentation and validation of the power restoration function (NRF).
•
ESF for Event Synthesis Function (alarm processing and diagnosis)
•
NRF for Network Restoration Function. NRF elaborates restoration plans using remote controled devices;
•
FL for Fault Location function that manages the identification of the fault location on a feeder.
Some other functions (study mode, assistance to repair, etc) are also proposed in the AUSTRAL package, but will not be described in this paper.
486
3.1 Events and alarms analysis (ESF) Many automatic devices operate on the network itself. These devices return a substantial amount of information for display to the operator, and some remote signals perform an alarm function. In certain situations the operator may be required to cope with an avalanche of events, and interpretation of the information return can become very difficult. The first objective of the ESF function is therefore to reduce the total amount of data presented to the operator. To carry out this task, sets of coherent remote signals are combined to form a single synthetic data entity. From the operator's point of view, the original General Summary, displaying all remote information, will be supplemented by a synthetic summary managed by AUSTRAL. The second objective of ESF is to provide a deeper analysis of incoming events, in terms of outage diagnosis. Around 20 types of synthesis and diagnosis have been identified. Synthesis usually involves interpreting the behaviour of the automatic device. Diagnosis is also based on event synthesis, but also provides an explanation of the cause as well. All diagnoses are triggered by a permanent breaker opening.
it provides the ability to deal with expected nonoccurence of events (for instance, to descnbe that during a certain length of time, no fault should be detected by the protections, i.e. the fault has been cleared by automata) ;
•
it provides possibility to specify optional events (facultative events) that may produce a complement of the diagnosis message (for instance, a missing event may not invalidate the chronicle but will produce a warning).
3.2 Fault location The AUSTRAL fault location function (FL) is invoked when a permanent fault occurs on the network, causing circuit-breakers to remain permanently open. The defective section must be located and isolated, before trying to restore the power to the fault-free sections. AUSTRAL uses the fault detectors information to deduce the fault location. Several different hypothesis are built including some considering wrong behavior of fault detectors. It allows to handle inconsistent fault detector information. The location is given as a remote controlled switching section. In the case of competitive hypothesis, the different location hypothes are displayed to the operator. But, if all devices have properly worked, there is often only one hypothesis that is obviously the best and is selected by AUSTRAL.
It is worth noting that ESF can diagnose an action of protections and automata after a fault occured. It can also diagnose a certain kind of wrong behaviors of protection devices. ESF inputs a stream of incoming time-stamped events. A set of events, occurring in a given temporal pattern, could develop into what we call a chronicle. ESF manages a set of predefmed chronicles and tries to match them against the incoming stream of events.
Fault location depends greatly on the fault detectors ' technology. The fault distance calculation is generally more precise that the single fault detector indication, and FL is able to manage all kind of information sent by fault detector devices. However it requires special devices measuring voltages and current signals that are generally not available on EDF networks.
A chronicle is described as a sequence of expected or unexpected events associated with time constraints. A specific event in a chronicle serves as a trigger event. The chronicle becomes active when this event is detected. ESF does not try to recognize the chronicle as it develops : a specific length of time is associated with each chronicle. This delay corresponds to the minimum length of time required for receiving all relevant events. The recognition process waits for expiration of this period and then, the sequence of registered events is compared with the chronicle. If the chronicle is partially or completely recognised, a message is sent to the operator, and if the chronicle corresponds to a diagnosis that calls for a restoration procedure, the NRF function is invoked.
3.3 Power restoration (NRF)
NFR. has to deal with various kind of faults. The most commonplace are localised faults on MV feeders, which cause the circuit-breaker upstream of the feeder to remain open (meaning that the automatic device was not able to clear the fault) . But more serious incidents (known as generalised faults) may occur in the form of busbar faults or HVIMV transformer outages. These incidents deenergise many feeders, making the restoration process much more complex because of the higher number of constraints involved. For these outages, AUSTRAL is expected to provide a very valued assistance to operators.
The main features of the temporal reasoning engine in ESF are as follows: •
•
it takes into account the actual topology and the actual configuration of automata (for instance, the feeder really coonected to the HVIMV transformer when the fault occured, or the actual topology in the primary substation) ;
NRF is invoked after ESF has detected a permanent fault and FL has located the fault if this fault is on a feeder. NRF is provided with identification details on
487
functions not available in the basic SCADA package can be added on to meet specific end user demand as required. In practice, the connection of advanced functions such AUS1RAL to existing SCADA systems is a much more complicated matter, especially for realtime functions.
the fault and a description of the breakers that switched off. NRF will then elaborate a set of restoration plans. In interactive mode, all generated plans with their respective characteristics are displayed to the operator. The system highlights the plan that it considers to be the best choice, but the operator is responsible for selection and application. Initially, AUS1RAL will only be used in interactive mode. After a successful period in interactive mode, automatic mode will be gradually phased in for certain restoration procedures considered to be simple and well specified (e.g. power restoration on feeder).
The AUS1RAL experiment was a good oportunity to evaluate these claims. AUS1RALis being to become operational on SINAUT-Spectrum (SIEMENS) and SIT-R (EDF). A feasabilty study is currently carried out for the connection to the CEGELEC-ESCA SCADA (DMP). EDF has decided that connections should operate via a set of Application Program Interfaces (APIs). These APIs make the connection explicit in terms of data exchanges and SCADA services. The API is part of the basic SCADA. It means that the SCADA provider should guarantee upward compatibility. By this way, EDF hope to be able to keep control on telecontrol softwares implemented in they distribution control centers.
The restoration process perfonned by NRF uses remote-controlled equipment only. For restoring the power downstream of a fault, the system must determine the downstream area's former consumption and decide whether this consumption can be transferred to one or more emergency feeders, in compliance with maximum admissible current intensities for all system sections. Customer re-energising strategies must accommodate several criteria such as minimising the number of switching operations, guaranteeing power for the next load peak, balancing emergency feeders, rapidly re-energising sensitive customers, etc.
In the following, we discuss the requirements of AUS1RAL in tenns of SCADA services. All this services are presented in terms of API in the current experiences (SIEMENS, CEGELEC, EDF SIT-R, etc.). Discussion on some difficulties encoutered and some lessons learned so far has been provided in (Krivine, et aI., 1996b).
The NRF function accomodates the operator with level-I , level-2 and partial plans. A level-l plan only uses emergency feeders that are directly connected to the area to be supplied. Level-2 plans partly transfer the emergency feeder load to a third feeder before using it. Partial plans (level I or level 2) re-energise only part of fault-free areas since complete plans reenergize the entire network and isolate the exact fault area. Of course, AUS1RAL first tries to generate full level-l plans. But this is not always possible, specially for a HV/MV substation fault.
4.2 API requirements
Data exchange is the most important and the most difficult topic. The SCADA has its own data model that cannot be similar to the model used by AUS1RAL. Performance for real-time operation is the major concern for the SCADA database. Conversaly, AUSTRAL needs a well structured object-oriented model. Defining a common model that can be shared by both advanced functions (like AUSTRAL) and SCADA, remains an open problem. This topic is addressed by the Electric Power Research Institute (EPRI), which has initiated a project to define a set of Control Centre Application Program Interface (CCAPI) Guidelines with a view to developing "plug-in" applications for an Energy Management System (EMS) (EPRI 1996).
4. CONNECTION TO A SCADA
4.1 How can AUSTRAL functions be connected to existing telecontrol systems? The connection of AUS1RAL to an existing SCADA raises two kinds of issues. From a technical point of view, the services provided by the SCADA should be powerfull enough to enable the AUS1RAL function to run properly. We will see that data access is the most critical point. But another point is paramount. API addresses the long term interest of the utility and the control and the independance electric utilities should keep from SCADA providers for further evolutions.
However, these guidelines are not yet in widespread use, so data exchange and SCADA services requirements should be handled in a more or less adhoc manner. Morover, even in the case of a common model, data sharing remains unsolved. For integrity and performance reasons, the available SCADA does not allow external functions to perform read-write access to the real-time database.
SCADA systems available on the market are making increasing use of standard technology. (UNIX, TCPIIP, MOTIF, etc.). The vendors of these telecontrol systems all claim to offer open architecture as one of the main features. Theoretically, this should mean that extra
488
Static data are data describing network components (busbars, switching devices, operational equipment), connections, and physical and electrical characteristics. Static data are acquired by calling a set of API functions upon initialisation of communication with the SCADA They are used to build an image of the actual database.
Ouerying fault detectors Not all fault detectors return messages systematically whenever they detect a fault. For this reason, a special API function has been designed to poll the detectors and return relevant data This function will be used by AUSTRAL to locate faults when a breaker opens.
Dynamic data concern real-time changes (remote measurements or remote signals sent by automatic control systems, switching operations or fault detectors). These data are delivered in real-time by a dedicated API (notification).
Network calculations and other services Many Telecontrol Systems, provides a set of computation functions (load-flow, voltage calculation, etc.). These are known as Distribution Management System (DMS) functions in the distribution network context. Access to these services is an important requirement for advanced function connectability as far as we want to avoid duplicating this calculation again in the AUSTRAL platform. For this reason, a set of APls has been defined for calling these computation programs (load flow in branch and voltage at nodes; load evaluation; power available at node; short-circuit current on device).
Managing an up-to-date image of the real time database is a quite difficult task performed in the AUSTRAL platform (Krivine, et al.. 1996a). It requires to perform a translation from the SCADA model to the AUSTRAL object-oriented model. It also needs to respect real-time constraints upon notification of dynamic data variation. Remote orders and switchin~ seqyences
Study mode
An API function implements remote orders (switching actions). It is required for the NRF automatic mode.
Study mode, an important feature of telecontrol systems, is derived from a copy of the real-time network or from a network description stored in archives. In study mode, the operator can simulate situations and evaluate alternative actions. Some of the functions developed for real-time operation may be relevant for study mode. A set of API functions has been designed for managing study mode in a similar way to the real-time network (static data initialisation, update, etc.).
The SCADA can also manage switching sequences. A switching sequence is a list of orders created by operators for remote-controlled devices. A switching sequence can be displayed, updated, deleted and, of course, applied to the network. A switching sequence can also be applied in study mode. A set of API functions handles the creation and deletion of switching sequences, which are then managed in the same way as those created by the operator.
Connection mana~ement Operator interface A final API set handles the hook-up with the telecontrol system. The server running the external function (AUS1RAL) must be considered as a server in the telecontrol system and managed accordingly (initialisation, shutdown, errors, etc.).
One major requirement for additional functions such as AUSTRAL is that they should conform to common Man-Machine Interface (MMI) standards. To ensure operator acceptance, functions must avoid "look and feel" conflicts. A set of API functions handles major MM! services: -
transmission of messages to the general summary;
-
management of a specific summary ;
4.3 Implementation issues Sinayt Spectrum (SIEMENS)
-
management of graphic widgets in common graphic representations (by updating the corresponding attributes in the database);
-
call-back attached to operator menus.
The API software is written in PASCAL at the top of the SINAUT Spectrum. It is based on the Soft-Bus protocol designed by SIEMENS to handle communication between the SCADA modules. It implements a 26-function library to be linked with the AUSTRAL application. The API developed is specific to the SINAUT Spectrum but the functions proposed are fairly general.
Of course, specific windows can be designed using MOTIF standards.
An Interface Module (lM) performs the translation from the SCADA model to the AUSTRAL model. It
489
However, for EDF, the API experiment yields valuable results, not only as regards control over future extensions, but also in tenns of evaluation for open access to the SCADA system. Some portions of the APls were fairly easy to define and specify, though others proved more complex. By studying these technical difficulties, we will clearly improve our understanding of the SCADA system.
makes the AUSTRAL functions independent of the SCADA and improves data access. Conversely the AUSTRAL functions ask the IM when they need to activate a SCADA service. To connect AUSTRAL functions to other SCADAs, the developper has to adapt the IM only. At initialisation of the API, the Interface Module builds the AUSTRAL data model using the static data and the current values of the dynamic data The IM then makes a read call to receive events. On each event, the IM updates its data and sends it to the correct AUSTRAL function which processes it and asks the IM when API calls need to be made.
EDF hopes that the main benefit offered by the experiment will be to validate the API set for hooking up to new functions it might develop or acquire on the market, and also connecting AUSTRAL on new control centers over the world and on new platform.
DMP (ESCA-CEGELEC) The approach studied in the «feasability study» is quite similar to the one done with SIEMENS. It is important to notice that managing an AUSTRAL independant database enable us to reuse the development done for SIEMENS (except the IM module for data translation). This way ensure an independance of AUSTRAL and its multi-platform feature. SIT-R cEDE)
6. REFERENCES Bredillet P. , I. Delouis-Jacob, P. Eyrolles, O. Jehl, J-P. Krivine and P. Thiault (1994). The AUSTRAL Expert System for Power Restoration on Distribution Systems; Intelligent Systems, Application to Power Systems (ISAP'94), Montpellier, France 1994. EPRI (1996). EPRI Control Center API Project (RP 3654-1) "Control Center API Guidelines / Introduction".
I
In this experimentation, we are studying the possibility to share a common object-oriented database using interoperability features (CORBA).
5. CONCLUSION
Krivine J-P . and O. Jehl (1996a). The AUSTRAL System for DIAGNOSIS and POWER restoration : an overview ; Jean-Paul Krivine and Olivier Jehl. Intelligent Systems, Application to Power Systems (ISAP'96) , Orlando, USA 1996.
AUSTRAL is a quite general and evolutive software package for distribution network operation. It will be operational by the beginning of 1998 on three French distribution control center. AUSTRAL is available on various platform.
Krivine J-P, T. Deneux, G. Delatouche and P. Thiault (1996b). Application Program Interfaces for Connecting Advanced Functions to Telecontrol System: the AUSTRAL experiment ; PSCC, Dresdes, Germany. 1996.
Factory acceptance tests (FAT) for the initial API of SINAUT-Spectrum version were completed by the end of 1995. Feasability study is well engaged with CEGELEC. This means we are now in a good position to stand back from the experiment and offer a balanced commentaIy. This has been started in (Krivine, et al., 1996b).
Liu C-C., and T. Dillon (1992). State of the art in expert system applications for power systems. International Journal of Electrical Power & Energy Systems, Volume 14 (Expert Systems Applications in Power Systems), Number 2/3 p. 88, 1992.
From a practical point of view, the most difficult point concerns data exchange. Translation from one model (the SCADA model) to another one (the AUSTRAL model) is always a tricky task, specially when the models are conceptulaly far one from the other (hierarchically structured versus object oriented). The connection to a new SCADA or the intsallation into another distribution center is often a more longer task than expected.
490
Electricite de France Research and Development Division, Power System Department 1, avenue du General De Gaulle - 92140 Clamart - France Telephone: (+ 33) 147654321 - E-Mail :
Abstract: To improve distribution network efficiency, EDF is developing AUSTRAL, a package of real-time functions for alarm processing, diagnosis and service restoration. AUS1RAL will become operational at the beginning of 1998 in three French control centers (Lyon, Nimes and Versailles). The main aim of the AUSTRAL system is to cut overall outage time. AUSTRAL is a fully integrated system that shares data and MM! (Man-Machine Interface) with the telecontrol system (SCADA). It operates directly on real time data. AUSTRAL is a multi-platform package that may run on several telecontrol systems. The connexion is made via an explicit interface (AP.I. for Application Program Interface) provided as part of the basic SCADA Copyright© 1998 IFAC Keywords : Distribution Network, Alarm processing, Power restoration, Expert systems, Connection to SCADA, Application Program Interface (API).
found to be de-energised, Figure 1 shows the general feedback loop linking the AUSTRAL functions.
1. INTRODUCTION To increase telecontrol efficiency, EDF's Research and Development Division is developing a set of advanced functions operating on real-time data supplied from a SCADA. The main objective is to reduce the overall · outage time. This goal will be achieved using two kinds of functions. The first one aims at increasing the understanding of operators of what is happening on the network. The Event Synthesis Function (ESF) will reduce the number of events displayed in the General SUIIl1IlaIY. A diagnosis task is also performed and will provide an explanation of the cause of main outages. The second set of functions aims at proposing actions to be carried out for solving some identified problems. The main function developed for this purpose in AUSTRAL is the NRF function (Network Restoration Function) which is invoked when part of the network is
The AUSTRAL functions operate directly on real time data. They input actual incoming remote signals and remote measurements, supplied by the telecontrol system via a standardised interface. The main objective is to deliver advanced functions to operators that are strongly integrated to the basic SCADA The AUSTRAL functions described in this section share the telecontrol system MM! and then present a quite unified look and feel. In the same way, there is no specific database for AUSTRAL. AUSTRAL uses the data stored in the common database. AUS1RAL doesn't need any specific data administration system.
485
The first operational version of the AUSTRAL is scheduled for delivery at three French centers (Lyon, Versailles and Nimes) at the beginning of 1998.
l~~~~~s~oss.Y.OSSS.~··~··~··r~~·s·~·~~~~i
i Type of reglOn ~ :r--.-
l
nuxed rural / ! urban
~ Number of customers
®I':;~~I
i
.---.....:;..,...--.-----~§
~
I I:::----
l 4000 GWh
i 700 l
Overhead lines
~
Cables
Number of substation Number of feeders
"
.
~ Dlsconne~J~~E.~eder ~
I~
Figure 1 : Functional overview
Remote controlled disconnectors Eer feeder
~ Fault detectors per feeder
~
This paper presents a full description of the AUSTRAL system. Section 2 starts with a brief description of the French distnbution networks, and sumarize the current state of the project. Section 3 provides an in-depth description of the main AUSTRAL functions (NRF, FL and ESF). Section 4 discusses the hook-up to the telecontrol system.
~
km
~ ~
I
l 2700 km
~
I 18 l; 275
~
l.
~
l~ 3 (remote
~
.;..-~----~ ~ ~
~
I
8§5 000
,~
~ En~~ consS!tion Eer ~ear ~
®[email protected];;Q
~ ~
oeec:eeoeo::eceeoc:o
~
~
1 10i~~-J ~ 1 3 (in average) ~ ! ~
ce::e:e::el:e:~::~~~l~)
~
:oee=~
Figure 2 : Characteristics of a pilot site for AUSTRAL
3. DESCRIPTION OF THE AUSTRAL FUNCTIONS AUSTRAL is composed of several functions directly connected to real-time data. They are automatically triggered according to network events and results of previously activated functions. For instance, power restoration (NRF) should be triggered after the Event Synthesis Function has recognised a specific diagnosis and FL has localized the fault. Some important synchronisation between functions taking care of the network state is needed. A module, called Supervisor, is responsible for this task and manages the links to be established and the functions to be launched in each situation.
2. THE EDF DISTRIBUTION SYSTEM AND THE AUSTRAL SYSTEM EDF Medium Voltage (MV) distribution systems mainly operate at 20 kV. They are supplied by 63/20 kV, 90/20 kV and (occasionally) 220/20 kV substations. MV networks operate in a radial configuration but have a meshable structure. A MV feeder comprises about f"Ifty switching devices on average (located in the LV substations on underground networks or pole-mounted on overhead feeders) . Most of them are locally (i.e. manually) controlled. However a few elements (two or three per feeder on average) are remote controlled; these are generally located on the frames. Fault current detection devices, which indicate whether the failure has occurred downstream on the feeder, may be associated with the switching elements on both overhead and underground networks. Those associated with remote controlled elements are usually remote indicated. Figure 2 shows the characteristics of one of the control center that will host AUSTRAL in 1997.
The main AUSTRAL functions are the following:
The AUSTRAL project started in 1993 . Mter a successful prototyping of the power restoration function (Bredillet, et aL 1994), an industrial phase began in 1994. A preliminary off-line version has been delivered for experimentation and validation of the power restoration function (NRF).
•
ESF for Event Synthesis Function (alarm processing and diagnosis)
•
NRF for Network Restoration Function. NRF elaborates restoration plans using remote controled devices;
•
FL for Fault Location function that manages the identification of the fault location on a feeder.
Some other functions (study mode, assistance to repair, etc) are also proposed in the AUSTRAL package, but will not be described in this paper.
486
3.1 Events and alarms analysis (ESF) Many automatic devices operate on the network itself. These devices return a substantial amount of information for display to the operator, and some remote signals perform an alarm function. In certain situations the operator may be required to cope with an avalanche of events, and interpretation of the information return can become very difficult. The first objective of the ESF function is therefore to reduce the total amount of data presented to the operator. To carry out this task, sets of coherent remote signals are combined to form a single synthetic data entity. From the operator's point of view, the original General Summary, displaying all remote information, will be supplemented by a synthetic summary managed by AUSTRAL. The second objective of ESF is to provide a deeper analysis of incoming events, in terms of outage diagnosis. Around 20 types of synthesis and diagnosis have been identified. Synthesis usually involves interpreting the behaviour of the automatic device. Diagnosis is also based on event synthesis, but also provides an explanation of the cause as well. All diagnoses are triggered by a permanent breaker opening.
it provides the ability to deal with expected nonoccurence of events (for instance, to descnbe that during a certain length of time, no fault should be detected by the protections, i.e. the fault has been cleared by automata) ;
•
it provides possibility to specify optional events (facultative events) that may produce a complement of the diagnosis message (for instance, a missing event may not invalidate the chronicle but will produce a warning).
3.2 Fault location The AUSTRAL fault location function (FL) is invoked when a permanent fault occurs on the network, causing circuit-breakers to remain permanently open. The defective section must be located and isolated, before trying to restore the power to the fault-free sections. AUSTRAL uses the fault detectors information to deduce the fault location. Several different hypothesis are built including some considering wrong behavior of fault detectors. It allows to handle inconsistent fault detector information. The location is given as a remote controlled switching section. In the case of competitive hypothesis, the different location hypothes are displayed to the operator. But, if all devices have properly worked, there is often only one hypothesis that is obviously the best and is selected by AUSTRAL.
It is worth noting that ESF can diagnose an action of protections and automata after a fault occured. It can also diagnose a certain kind of wrong behaviors of protection devices. ESF inputs a stream of incoming time-stamped events. A set of events, occurring in a given temporal pattern, could develop into what we call a chronicle. ESF manages a set of predefmed chronicles and tries to match them against the incoming stream of events.
Fault location depends greatly on the fault detectors ' technology. The fault distance calculation is generally more precise that the single fault detector indication, and FL is able to manage all kind of information sent by fault detector devices. However it requires special devices measuring voltages and current signals that are generally not available on EDF networks.
A chronicle is described as a sequence of expected or unexpected events associated with time constraints. A specific event in a chronicle serves as a trigger event. The chronicle becomes active when this event is detected. ESF does not try to recognize the chronicle as it develops : a specific length of time is associated with each chronicle. This delay corresponds to the minimum length of time required for receiving all relevant events. The recognition process waits for expiration of this period and then, the sequence of registered events is compared with the chronicle. If the chronicle is partially or completely recognised, a message is sent to the operator, and if the chronicle corresponds to a diagnosis that calls for a restoration procedure, the NRF function is invoked.
3.3 Power restoration (NRF)
NFR. has to deal with various kind of faults. The most commonplace are localised faults on MV feeders, which cause the circuit-breaker upstream of the feeder to remain open (meaning that the automatic device was not able to clear the fault) . But more serious incidents (known as generalised faults) may occur in the form of busbar faults or HVIMV transformer outages. These incidents deenergise many feeders, making the restoration process much more complex because of the higher number of constraints involved. For these outages, AUSTRAL is expected to provide a very valued assistance to operators.
The main features of the temporal reasoning engine in ESF are as follows: •
•
it takes into account the actual topology and the actual configuration of automata (for instance, the feeder really coonected to the HVIMV transformer when the fault occured, or the actual topology in the primary substation) ;
NRF is invoked after ESF has detected a permanent fault and FL has located the fault if this fault is on a feeder. NRF is provided with identification details on
487
functions not available in the basic SCADA package can be added on to meet specific end user demand as required. In practice, the connection of advanced functions such AUS1RAL to existing SCADA systems is a much more complicated matter, especially for realtime functions.
the fault and a description of the breakers that switched off. NRF will then elaborate a set of restoration plans. In interactive mode, all generated plans with their respective characteristics are displayed to the operator. The system highlights the plan that it considers to be the best choice, but the operator is responsible for selection and application. Initially, AUS1RAL will only be used in interactive mode. After a successful period in interactive mode, automatic mode will be gradually phased in for certain restoration procedures considered to be simple and well specified (e.g. power restoration on feeder).
The AUS1RAL experiment was a good oportunity to evaluate these claims. AUS1RALis being to become operational on SINAUT-Spectrum (SIEMENS) and SIT-R (EDF). A feasabilty study is currently carried out for the connection to the CEGELEC-ESCA SCADA (DMP). EDF has decided that connections should operate via a set of Application Program Interfaces (APIs). These APIs make the connection explicit in terms of data exchanges and SCADA services. The API is part of the basic SCADA. It means that the SCADA provider should guarantee upward compatibility. By this way, EDF hope to be able to keep control on telecontrol softwares implemented in they distribution control centers.
The restoration process perfonned by NRF uses remote-controlled equipment only. For restoring the power downstream of a fault, the system must determine the downstream area's former consumption and decide whether this consumption can be transferred to one or more emergency feeders, in compliance with maximum admissible current intensities for all system sections. Customer re-energising strategies must accommodate several criteria such as minimising the number of switching operations, guaranteeing power for the next load peak, balancing emergency feeders, rapidly re-energising sensitive customers, etc.
In the following, we discuss the requirements of AUS1RAL in tenns of SCADA services. All this services are presented in terms of API in the current experiences (SIEMENS, CEGELEC, EDF SIT-R, etc.). Discussion on some difficulties encoutered and some lessons learned so far has been provided in (Krivine, et aI., 1996b).
The NRF function accomodates the operator with level-I , level-2 and partial plans. A level-l plan only uses emergency feeders that are directly connected to the area to be supplied. Level-2 plans partly transfer the emergency feeder load to a third feeder before using it. Partial plans (level I or level 2) re-energise only part of fault-free areas since complete plans reenergize the entire network and isolate the exact fault area. Of course, AUS1RAL first tries to generate full level-l plans. But this is not always possible, specially for a HV/MV substation fault.
4.2 API requirements
Data exchange is the most important and the most difficult topic. The SCADA has its own data model that cannot be similar to the model used by AUS1RAL. Performance for real-time operation is the major concern for the SCADA database. Conversaly, AUSTRAL needs a well structured object-oriented model. Defining a common model that can be shared by both advanced functions (like AUSTRAL) and SCADA, remains an open problem. This topic is addressed by the Electric Power Research Institute (EPRI), which has initiated a project to define a set of Control Centre Application Program Interface (CCAPI) Guidelines with a view to developing "plug-in" applications for an Energy Management System (EMS) (EPRI 1996).
4. CONNECTION TO A SCADA
4.1 How can AUSTRAL functions be connected to existing telecontrol systems? The connection of AUS1RAL to an existing SCADA raises two kinds of issues. From a technical point of view, the services provided by the SCADA should be powerfull enough to enable the AUS1RAL function to run properly. We will see that data access is the most critical point. But another point is paramount. API addresses the long term interest of the utility and the control and the independance electric utilities should keep from SCADA providers for further evolutions.
However, these guidelines are not yet in widespread use, so data exchange and SCADA services requirements should be handled in a more or less adhoc manner. Morover, even in the case of a common model, data sharing remains unsolved. For integrity and performance reasons, the available SCADA does not allow external functions to perform read-write access to the real-time database.
SCADA systems available on the market are making increasing use of standard technology. (UNIX, TCPIIP, MOTIF, etc.). The vendors of these telecontrol systems all claim to offer open architecture as one of the main features. Theoretically, this should mean that extra
488
Static data are data describing network components (busbars, switching devices, operational equipment), connections, and physical and electrical characteristics. Static data are acquired by calling a set of API functions upon initialisation of communication with the SCADA They are used to build an image of the actual database.
Ouerying fault detectors Not all fault detectors return messages systematically whenever they detect a fault. For this reason, a special API function has been designed to poll the detectors and return relevant data This function will be used by AUSTRAL to locate faults when a breaker opens.
Dynamic data concern real-time changes (remote measurements or remote signals sent by automatic control systems, switching operations or fault detectors). These data are delivered in real-time by a dedicated API (notification).
Network calculations and other services Many Telecontrol Systems, provides a set of computation functions (load-flow, voltage calculation, etc.). These are known as Distribution Management System (DMS) functions in the distribution network context. Access to these services is an important requirement for advanced function connectability as far as we want to avoid duplicating this calculation again in the AUSTRAL platform. For this reason, a set of APls has been defined for calling these computation programs (load flow in branch and voltage at nodes; load evaluation; power available at node; short-circuit current on device).
Managing an up-to-date image of the real time database is a quite difficult task performed in the AUSTRAL platform (Krivine, et al.. 1996a). It requires to perform a translation from the SCADA model to the AUSTRAL object-oriented model. It also needs to respect real-time constraints upon notification of dynamic data variation. Remote orders and switchin~ seqyences
Study mode
An API function implements remote orders (switching actions). It is required for the NRF automatic mode.
Study mode, an important feature of telecontrol systems, is derived from a copy of the real-time network or from a network description stored in archives. In study mode, the operator can simulate situations and evaluate alternative actions. Some of the functions developed for real-time operation may be relevant for study mode. A set of API functions has been designed for managing study mode in a similar way to the real-time network (static data initialisation, update, etc.).
The SCADA can also manage switching sequences. A switching sequence is a list of orders created by operators for remote-controlled devices. A switching sequence can be displayed, updated, deleted and, of course, applied to the network. A switching sequence can also be applied in study mode. A set of API functions handles the creation and deletion of switching sequences, which are then managed in the same way as those created by the operator.
Connection mana~ement Operator interface A final API set handles the hook-up with the telecontrol system. The server running the external function (AUS1RAL) must be considered as a server in the telecontrol system and managed accordingly (initialisation, shutdown, errors, etc.).
One major requirement for additional functions such as AUSTRAL is that they should conform to common Man-Machine Interface (MMI) standards. To ensure operator acceptance, functions must avoid "look and feel" conflicts. A set of API functions handles major MM! services: -
transmission of messages to the general summary;
-
management of a specific summary ;
4.3 Implementation issues Sinayt Spectrum (SIEMENS)
-
management of graphic widgets in common graphic representations (by updating the corresponding attributes in the database);
-
call-back attached to operator menus.
The API software is written in PASCAL at the top of the SINAUT Spectrum. It is based on the Soft-Bus protocol designed by SIEMENS to handle communication between the SCADA modules. It implements a 26-function library to be linked with the AUSTRAL application. The API developed is specific to the SINAUT Spectrum but the functions proposed are fairly general.
Of course, specific windows can be designed using MOTIF standards.
An Interface Module (lM) performs the translation from the SCADA model to the AUSTRAL model. It
489
However, for EDF, the API experiment yields valuable results, not only as regards control over future extensions, but also in tenns of evaluation for open access to the SCADA system. Some portions of the APls were fairly easy to define and specify, though others proved more complex. By studying these technical difficulties, we will clearly improve our understanding of the SCADA system.
makes the AUSTRAL functions independent of the SCADA and improves data access. Conversely the AUSTRAL functions ask the IM when they need to activate a SCADA service. To connect AUSTRAL functions to other SCADAs, the developper has to adapt the IM only. At initialisation of the API, the Interface Module builds the AUSTRAL data model using the static data and the current values of the dynamic data The IM then makes a read call to receive events. On each event, the IM updates its data and sends it to the correct AUSTRAL function which processes it and asks the IM when API calls need to be made.
EDF hopes that the main benefit offered by the experiment will be to validate the API set for hooking up to new functions it might develop or acquire on the market, and also connecting AUSTRAL on new control centers over the world and on new platform.
DMP (ESCA-CEGELEC) The approach studied in the «feasability study» is quite similar to the one done with SIEMENS. It is important to notice that managing an AUSTRAL independant database enable us to reuse the development done for SIEMENS (except the IM module for data translation). This way ensure an independance of AUSTRAL and its multi-platform feature. SIT-R cEDE)
6. REFERENCES Bredillet P. , I. Delouis-Jacob, P. Eyrolles, O. Jehl, J-P. Krivine and P. Thiault (1994). The AUSTRAL Expert System for Power Restoration on Distribution Systems; Intelligent Systems, Application to Power Systems (ISAP'94), Montpellier, France 1994. EPRI (1996). EPRI Control Center API Project (RP 3654-1) "Control Center API Guidelines / Introduction".
I
In this experimentation, we are studying the possibility to share a common object-oriented database using interoperability features (CORBA).
5. CONCLUSION
Krivine J-P . and O. Jehl (1996a). The AUSTRAL System for DIAGNOSIS and POWER restoration : an overview ; Jean-Paul Krivine and Olivier Jehl. Intelligent Systems, Application to Power Systems (ISAP'96) , Orlando, USA 1996.
AUSTRAL is a quite general and evolutive software package for distribution network operation. It will be operational by the beginning of 1998 on three French distribution control center. AUSTRAL is available on various platform.
Krivine J-P, T. Deneux, G. Delatouche and P. Thiault (1996b). Application Program Interfaces for Connecting Advanced Functions to Telecontrol System: the AUSTRAL experiment ; PSCC, Dresdes, Germany. 1996.
Factory acceptance tests (FAT) for the initial API of SINAUT-Spectrum version were completed by the end of 1995. Feasability study is well engaged with CEGELEC. This means we are now in a good position to stand back from the experiment and offer a balanced commentaIy. This has been started in (Krivine, et al., 1996b).
Liu C-C., and T. Dillon (1992). State of the art in expert system applications for power systems. International Journal of Electrical Power & Energy Systems, Volume 14 (Expert Systems Applications in Power Systems), Number 2/3 p. 88, 1992.
From a practical point of view, the most difficult point concerns data exchange. Translation from one model (the SCADA model) to another one (the AUSTRAL model) is always a tricky task, specially when the models are conceptulaly far one from the other (hierarchically structured versus object oriented). The connection to a new SCADA or the intsallation into another distribution center is often a more longer task than expected.
490