LIB 500 Application - ABB Group 500 Application database (objects) Standard Functions Engineering...

MicroSCADA Application Library

Product Guide

LIB 500

LIB 500 Application

database

(objects)

pictureEngineeringStandard Functions

parameterizinginstallation

name parameter aparam . . ................................................................

Configurationfile


Product Guide

LIB 5001MRS750444-MBG

Issued: April 1999Status: Updated Version: C/09.05.2006Data subject to change without notice

3

Features • Fast and effective application engineering with pre-built library modules supporting ABB’s product range for substation auto-mation

• Base functions for the application engi-neering

• Background picture for all applications with header, pull-down menus and shortcut functions

• Authorization handling function

• Alarm list with two templates and filtering functions

• Event list with filtering functions

• Blocking list

• System self-supervision handling function

• Busbar colouring function

• Data base import/export function

• Language converter function

Application The LIB 500 4.0.1 Application Software Library consists of product packages for building applications. It includes pictures, dialogs and application objects for local and remote monitoring and control of power transmission and distribution substations. LIB 500 is intended for local engineering centres to make it easier, faster and safer to engineer systems for their local customers.

As ABB has a wide variety of terminal prod-uct families delivered by the different product centres, an agreement has been made that each product centre supports their own prod-ucts to be able to cope with product revision handling and to react fast when new products are released. LIB 500 is therefore divided into four product packages at present:

• The LIB 500 Base package includes the common application platform functional-ity and is always required when the Appli-cation Software Library is used

• The LIB 510 medium-voltage process package supports products manufactured by ABB Transmit Oy, Vaasa, Finland (FIMIT) Product Centre, e.g. SPACOM protection and control terminals, SACO annunciator terminals, REF 54x protection and control terminals, SRIO gateways, RTU 2xx remote terminal units, and some other products

• The LIB 520 high-voltage process package supports products coming from ABB Net-work Partner, Västerås, Sweden (SENET) Product Centre: REL 5xx protection termi-nals, RET 5xx protection terminals, REB 5xx protection terminals, REC 561 control terminals, REO 500 protection and control terminals

• The LIB 530 high-voltage process package supports products coming from ABB Net-work Partner, Baden, Switzerland (CHNET) Product centre: RE. 216 protec-tion terminals, RE. 316 protection termi-nals, RE. 316*4 protection and control terminals, TCS1.10 MK30E voltage regu-lators (Reinhausen)

• The SIGTOOL signal engineering package coming from ABB Network Partner, Baden, Switzerland (CHNET)


Product Guide


Fig. 1 Library package structure

LIB 510•MV process

• SPACOM relay tools• REF 56. relay tools• Disturbance rec. tool• Trend reports• Measurement reports•

MV Process HV Process Local adaptationHV ProcessLIB 520•HV/Control

•HV/REx5xx•HV/collect•

LIB 530•HV process

•R..16/*4 relay tool•Reinhausen tool•Disturbance rec. tool •Sequence Controller •D 20 Gateway handling

LIB 500Base

•Back Bone functions- Application setting- Help Dialog- Basket

- User Management- SIGTOOL import/export- Installation tool- Configuration tool

•Event & Alarm Handling•Busbar colouring•System Self Supervision•Language converter

LIB 5__••••

SIGTOOL

Design Application engineeringToday there are two complementary applica-tion engineering methods to be used for creat-ing MicroSCADA applications. One method is to build the application from the beginning using the SCIL language and the other one is to use the LIB 500 Application Software Library. The SCIL method offers total flexi-bility, but lacks standard solutions. The train-ing and know-how level of the engineers ought to be high and the testing of the appli-cation is extensive. On the other hand, when using the LIB 500 method the application engineering is performed by composing LIB 500 standard functions to pictures. The appli-cation objects connected to various process functions are automatically created together with the graphical presentations and dialogs when the standard functions are installed in the application pictures. All the functions are type-tested and the complexity hidden in standard functions allows a lower entry level for the engineering. In many cases, when spe-cific customizations are needed, a combina-tion of the LIB 500 and the SCIL methods is used.

Extensions of existing applicationsApplications built with MicroLIBRARY ver-sions from 3.1 on can be used in an applica-tion built with LIB 500 4.0.1, as separate pictures. It is not possible to combine them into the same picture. LIB 500 is, as far as possible, made to support earlier applications

in respect of authorization handling, event and alarm lists, trend reports and measure-ment reports.

Standard functionsBy using standard functions, several types of process pictures may be created in an applica-tion. A standard function may contain all available picture elements, such as back-ground, start, update and exit programs and function keys. The only restriction, in techni-cal respect, is that it must not contain another standard function. The visual background may, in principle, be of any size. Standard functions are created with the picture editor.

The standard functions are grouped and orga-nized in a menu structure in accordance with their purpose.

The LIB 500 Base package is used as a base for the application design. The process pic-tures and the data objects are generated by installing standard function building blocks into the base picture containing the header and the base functionality.

Picture functionThe application pictures are composed of pic-ture function elements (also other picture ele-ments may be included). When a standard function is installed into an application pic-ture, it becomes a picture function.

4


Product Guide


Design (cont´d)

5

A picture function is a part of the application picture though it has its own picture elements such as picture background, start, update and exit programs, function keys and windows. Each picture function is given a name that must be unique within the picture. A picture function may be repositioned. All elements of a picture function can be viewed.

LIB 500 Base components

Backbone functionsThis standard function is used as a base pic-ture in all LIB 500 applications regarding menu configuration and default links from the default menu items.

The base picture which acts as a background for the application pictures contains a header with time and date presentation, pull-down menus and some shortcut push-buttons. The pull-down menus may be edited.

In addition, the backbone package includes a start-up picture, accessory pictures, the pic-ture for password handling, automatic print-out picture, basket picture and notebook.

Fig. 2 Some backbone pictures

Backbone function features• title bar• date and time presentation• toolbar shortcuts to event and alarm lists• alarm indication

• alarm row drop-down for alarm acknowl-edgment

• local/remote indication• system debugging tool


Product Guide


Design (cont´d) • application setting tool: language settings, time-out for log-ins, process control set-tings such as close/keep dialog after con-trol execution

• print/do not print user name on control execution

• note marker• help in all dialogs• title bar• SigTOOL import/export• User management tool

SigTOOL import/exportThis is a first step in the process of harmoni-zation of the LIB 500 and SigTOOL engi-neering environments. The purpose is to simplify application engineering and make it more effective. The MicroSCADA applica-tion database can be created either by using the LIB 500 standard functions, or by using the SigTOOL. Both methods have advan-tages, and in order to combine all advantages, a link is provided between LIB 500 and Sig-TOOL. In the future combined method, appli-cation engineering is performed roughly as follows:

• A ‘draft’ application database is created, along with the application pictures, using the LIB 500 standard function

• This ‘draft’ is transferred to SigTOOL using the import/export tool

• Signal engineering is performed with the SigTOOL

• The modified database is brought back to the MicroSCADA application using the same import/export tool. This tool can also be used for general purpose database import and export

User management toolThe application framework contains a user authorization mechanism with four user lev-els

• VIEW LEVEL. The operator is allowed to view the application, but is not allowed to make control operations, nor to use the programming and system configuration tools. Default setting for new users is the view level

• CONTROL LEVEL. The operator is allowed to make control operations, but has no access to the engineering and sys-tem configuration tools

• ENGINEERING LEVEL. All rights are granted, excluding user management

• SYSTEM MANAGEMENT LEVEL. This is the system manager level. All rights are granted, including the rights to add and remove users. Each application has one and only one system manager

The individual application objects can be grouped to programmable authorization groups. For each user it is possible to give a certain user level for each authorization group. If an object is not defined for a speci-fied authorization group, it is part of the gen-eral group.

In addition, a workstation with a unique IP address can be programmed to VIEW mode only. If this function is not programmed, the normal authorization mechanism will be used for the workstation.

6


Product Guide


Fig. 3 Authorization profile example

User 1

User 2

User 3

0

1

2

3

110k

V Brea

kers

20kV

Bre

akers

11kV

Brea

kers

Relay S

etting

Genera

l

View

Control

Engineering

Management

Programmable authorization groups

Aut

horiz

atio

n le

vel

Design (cont´d)

7

Alarm list functionThe alarm list displays the present alarm situ-ation of the process supervised. Each alarm is presented as an alarm predefined text line which describes the alarm in the process. The alarm text line consists of a time stamp, object identification, a signal text and a text indicating alarm status. The alarms are shown in chronological order. The newest alarm can be presented on the top or at the end of the page.

The LIB 500 alarm list has two templates: template 1 and template 2. The user can select which one to use. The templates share some of the dialogs, some dialogs are template-spe-cific.

In template 1, alarms are presented in two separate lists: the upper one contains active acknowledged and unacknowledged alarms (persisting alarms), while the lower one con-tains inactive unacknowledged alarms (fleet-ing alarms). Both lists can be scrolled.

Fig. 4 Alarm list, template 1


Product Guide


Design (cont´d) Each alarm is presented as a single alarm text line. This text line consists of a time stamp (date and time), object identification (station name and bay name), signal text and status text. The length and position of each text col-umn can be defined within certain limits. The colour of each alarm type can be selected from a predefined set of nine colours.

The most significant feature in the LIB 500 alarm list template 2 is that while the list is open, also inactive acknowledged alarms are shown in the list. They are removed with the reset function or when the alarm list picture is closed. All alarms are shown on a single list containing 32 lines of alarms. A blinking character “*” indicates all unacknowledged alarms, both active and inactive.

Fig. 5 Alarm list, template 2

A single alarm is acknowledged by clicking the line of the desired alarm on the list. If the selected alarm is unacknowledged, the line is highlighted and the acknowledgment dialog is opened. At the same time, the alarm list is frozen to prevent unwanted scrolling.

Conditions are used when the user wants to concentrate on specific information contained in the alarm buffer. This is done by introduc-ing a criterion to filter out unwanted informa-tion. A single criterion or multiple criteria can be used. These criteria can be freely com-bined to create grid-like filters. Station, bay and device names can be saved in an applica-tion-specific text file.

Alarm list features• two types of alarm list templates• time-based and object-based conditions:

time (lower and upper time limit, one sec-ond accuracy); five-level object identifica-tion structure, default levels are station (station names can be fetched from the process database), bay (bay names can be

fetched from the process database), device (device names can be fetched from the process database); function type (breakers, disconnectors, measurements, etc.); alarm class

• persisting and fleeting alarms separated• alarm list setting tool for colours and text

layout• updating/frozen presentation modes• alarm acknowledgment: single object, all

objects• alarm reset function• authorization support• help function available in all dialogs

Event list functionThe event list presents the process events from the monitored process in time order. Each event is normally presented by display-ing a predefined event text line which describes the event in the process. Event text lines consist of a time stamp, object identifi-

8


Product Guide


Design (cont´d)

9

cation, a signal text and a text indicating sta-tus. The events are presented in chronological order so that the latest event appears on the bottom line of the first page. The event list contains keys for browsing the list forward and backward.

Events are normally stored in the history buffer in the computer’s RAM memory, and they are also stored on the computer hard disk. The number of events that can be stored is limited by the size of the hard disk. The length of the history buffer is normally 10 000 events.

Fig. 6 Event list, main view

The default event text that describes the event consists of:

• status sign• time stamp• object identification• signal name• status textIn some applications, there is a need to change or to extend the text. It is then possi-ble to configure the length of the columns, the order of the columns and the column labels.

Conditions are used when the user wants to concentrate on specific information in the event list. This is done by introducing criteria to filter out unwanted information. One single criterion or multiple criteria can be used. These criteria can freely be combined to cre-ate grid-like filters. Station, bay and device names can be saved in an application specific text file.

Event list features• The event list layout is configurable.

Depending on the character type used, more than 80 characters per line are possi-ble

• Printouts are configurable• The event logfile is configurable to day

file, week file, month file, or year file• The amount of stored events is limited

only by the size of the hard disk• Supervision of available hard disk space.

The default limit value is 50 MB free space

• Scroll functions such as go to first page, scroll one line, scroll one page, scroll one interval or standard scrollbar

• Time-based and object-based conditions: time (lower and upper time limit, one sec-ond accuracy); five-level object identifica-tion structure, default levels are station (station names can be fetched from the process database), bay (bay names can be


Product Guide


Design (cont´d) fetched from the process database) and device (device names can be fetched from the process database); function type (breakers, disconnectors, measurements, etc.), alarm class

• updating/frozen presentation modes• authorization support• help function available in all dialogs

Blocking list functionThe blocking list is a summary display of the present blocking situation in the process which is supervised. Each blocked signal is

presented as a predefined signal text line. In addition to the signal text, a check box indi-cates the blocking status.

An object-blocking procedure is done by choosing it from the application picture or by request from the process database and conse-quently activating the chosen blocking condi-tion. Automatic blocking procedures are possible as well. For instance, when the sta-tion is switched for local control, all objects connected to the station can automatically be alarm-blocked.

Fig. 7 Blocking list example

The MicroSCADA version 8.4.1 provides a wide range of blocking attributes, which all are included in the blocking list as well. To provide a blocking handling mechanism in a more clear and rational way, the following blocking types are provided by the LIB 500 blocking list:

• alarm blocking: alarms are not raised, regardless of object state

• update blocking: indications are not updated from the process

• control blocking: operation commands are not sent to the process

• event blocking: event recordings are not made, events are not shown in the event list

• action blocking: event channel activation is blocked

Blocking list features• easy signal selection• selection of signals for blocking/deblock-

ing• blocking list setting tool• printout of blocking situation• printout blocking: events are not sent to

the printer

10


Product Guide


Design (cont´d)

11

• authorization support• help function available in all dialogs

System self-supervision functionThe system self-supervision function pro-vides standard functions for the supervision of system objects.

The system overview displays the status information of the hardware, system compo-nents, communication equipment and process control and protection units.

The status information of hardware and soft-ware can be displayed by both colour infor-mation or numerical information. The status information can also be stored in the history buffer and be set to give alarm at critical val-ues or limits.

Fig. 8 System self-supervision

System self-supervision features• DCP-NET and PC-NET supervision• NET line supervision• NET printer supervision• process control and protection unit super-

vision• X-monitor and VS-monitor supervision• help function available in all dialogs

Busbar colouring functionThe busbar colouring function provides dynamic colouring of the single-line diagram process picture.

The purpose of busbar colouring is to give the operator a quick overview of the actual state of the switchyard or network. The operator

should be able, at a glance, to see whether a busbar segment is earthed, energized or de-energized. This helps to prevent incorrect switching operations even when switching operations have to be performed in stress sit-uations.

Especially in large networks, the operator needs to know which bays are being supplied by which intake feeder (e.g. intake feeder, generators). Thanks to a better overview, undesired parallel switching of unsynchro-nized network parts can be prevented, and the operator can react quicker to the loss of an intake or generator.

The busbar colouring software package con-sists of three main components:


Product Guide


Design (cont´d)

12

• Single-line editor: It is used to create the single-line diagram for the switchyard and convert it into elements necessary for topology calculation.

• Topology Calculation: This consists of cal-culating the actual state of each of the bus-bar sections. The actual switch states are the input to topology calculation, and colouring of the individual busbar sections is the output. A new topology calculation will be triggered by a change in the state of a switch element.

• Topology Presentation: This consists of displaying the calculated colours for each of the busbar sections at the station level.

Fig. 9 Busbar colouring example

The user has the possibility to select between approximately 35 different colours.

Operating equipment such as transformers and reactors can either be coloured according to the appropriate busbar section or have a fixed colour which is independent of the topology.

The status of the switch elements and the colour (= priority) of the individual busbar sections are stored in the MicroSCADA pro-cess database

Busbar colouring features• fast recognition of infeed conditions• coloured sections in the single-line picture

show the state of the process

• energized, de-energized, earthed and unknown states are presented in different colours

• multiplied infeeds can be distinguished by different colours

• voltage levels (also transformer windings) can be distinguished by different colours

• freely definable colours• up to 200 stations, may be limited by com-

puter resources• up to 1000 switches per station• a single line may be spread over multiple

pictures• bidirectional connection to the topology

environment


Product Guide


Design (cont´d)

13

• creation of single lines supported by the single-line editor

Language converter functionThe language converter is a tool for the trans-lation of LIB 500 text files. It offers a transla-tion interface and the possibility to utilize

previous translations and keyword functions, which make the translation of repeated phrases and words faster.

Fig. 10 Language converter main view

Language converter features• support of the LIB 500 structure• support to use previous translations• support for three different text file formats

• fonts and maximum length of translation are changeable

• functions for adding, editing and using keywords

• help function available in all dialogs


Product Guide


Technical data Table 1: General requirementLIB 500 4.0.1 requires the MicroSCADA release 8.4.1 or newer.

All other product names are trademarks, registered trademarks, or service marks of their respective owners.

14

ABB OyDistribution AutomationP.O. Box 699 FI-65101 Vaasa, FINLANDTel +358 10 22 11Fax +358 10 224 1094www.abb.com/substationautomation

Date post:	11-Apr-2018
Category:	Documents
Upload:	dinhcong
View:	219 times
Download:	3 times

LIB 500 Application - ABB Group 500 Application database (objects) Standard Functions Engineering...

Documents