C.4.6.

NCC and TRCC Man Machine Interface

C.4.6.1. General Requirements

Interaction between NCC and TRCC operators and the monitored power system shall be
mainly carried out by the full graphic consoles, based on workstations, each one equipped
with three VDUs, one alphanumeric keyboard with numeric keypad and one cursor control
device.

NCC and TRCC displays shall be used to accomplish the main following tasks:

monitor and control the power system under the respective responsibility of each
control centre,
monitor and control the associated system configuration.

The other MMI equipment, such as printers, loggers, hard copy devices, digital displays
and mimic boards shall be used to enhance the operators interaction with the power
system.

The hardware description of the various NCC and TRCC MMI subsystems is detailed in
the section C.4.2 of technical specifications.

C.4.6.1.1. Standards

The proposed MMI software shall be compliant with the widely recognised X11
standard, associated with a Graphical User Interface (GUI) designed from de facto
standards, such as OSF/MOTIF.

C.4.6.1.2. Effective user interface

The following shall be the most important general principles for providing the effective
user interface:

design for usability,

avoid deductive designing,
ensure consistent design,
ensure consistent performance,
simplify navigation,
increase use of meaningful symbols,
use appropriate presentation,
hide details,
minimise clutter,
use colour effectively,
reduce track ball movements,
minimise typing by the user,
 support user preferences,
provide immediate feedback for actions.

C.4.6.1.3. Homogeneous user interface

It is essential that displays appear homogeneous. The number and types of tools or
applications used in the user interface system shall be transparent to end-users.

A common graphical user interface guideline shall be applied to design all displays. It
shall respect the general principles and shall allow:

same semantics for menus,

same operations on windows,
same interaction between windows,
same usage of track ball, buttons and keyboard,
same usage of graphical fonts and colours.

C.4.6.1.4. Window management

Each screen shall support multiple windows. It shall be possible to use each window
independently. Several windows shall be viewable on the screen at the same time. At a
given time, only one window shall be active. All operator actions shall be performed in
the active window, such as display call-up, panning and zooming, dialogue interactions.
The active window shall be easily recognisable by an indicator such as the colour of the
window border.

All windows shall include a title to identify the display and the current context.

The size and the location of any window shall be modifiable by the operator. In
addition, it shall be possible to define the maximum and minimum window size on a per
window basis. It shall be possible to iconify windows. The operations of resizing,
moving and iconifying windows shall be done with cursor and minimum number of
keystrokes.

A window can be occluded by another one.

It shall be possible to define a display as being locked into a window, so that no other
display can replace it.

C.4.6.1.5. Use of input devices

Accordingly to commonly accepted rules in standards such as OSF/Motif, extensive use

of trackball, keyboard function keys and soft keys shall be made. They shall be the
preferred way to interact with the software in order to navigate through the displays and
operate the system.

It shall be possible to pass from one VDU of an operator console to another one by
simply moving the trackball. Thus, the pointer shall go through the different VDUs as
soon as the pointer reaches each VDU edge, without any other operator action to
designate the active VDU.
 It shall be possible for the operators to adjust the acceleration, the speed of the cursor as
well as the double click speed.

The definition of the keyboard and pointing device shall be completely user definable,
as well as conditional, based on the display context.

C.4.6.1.6. Definable screen layout

At any time, the operator shall be given the possibility to save the screen layout, if
deemed of interest, in order to call it up again later on. The saved arrangement shall
include all currently open windows, along with their respective location on the screen
and content (i.e. display). Upon call-up of a previously saved screen layout, all windows
shall appear at their original screen location, and appropriate displays shall
automatically be called up into the corresponding windows. Screen layouts are given
names by the operator for save. The system shall keep track of all previously saved
screen layouts and present their names to the operator upon request.

For example, it shall be possible to create a predefined screen layout including:

A System zone (including general information such as date, time, state, load or
frequency and poke-points for displays navigation),
One or several Display zones (to call up any display),
An Alarm zone (including alarm markers and the most recent alarms occurrences).

C.4.6.1.7. On line help

An context sensitive on-line help facility shall be provided to assist operators in the
operation of the system.

C.4.6.2. User access

C.4.6.2.1. Security access

Two levels of system access security shall be provided:

System level:

It shall be possible to add or modify the list of identifiers (such as operator name
and/or mode of operation) and its assignments in order to supervise the access to
functions, displays and data for each console. It shall be possible to authorise any
task from any workstation (i.e. all workstations shall have complete functional
capabilities). Access control shall be based on permissions and area of responsibility.

Operator level:

It shall only be possible to access to the predefined functions, displays and data for
the console and the identifier.
The system shall allow several identifiers for each workstation. Only one identifier shall
be active at once on each workstation.

C.4.6.2.2. Log-on/Log-off

A user shall log on to the system at a console by entering an identifier and a password.

The specific functions, areas of responsibility and permissions shall be controlled

through log-on operation.

C.4.6.2.3. Area of responsibility

The monitored system shall be divided into several areas of responsibility for purpose of
limiting access. The concept of area of responsibility shall also be used for alarm
routing , alarm acknowledgement and supervisory control.

Each point of the monitored network shall be assigned to a single area of responsibility.
Any console assigned to this area of responsibility shall have responsibility for
controlling that point.

An attempt to perform an action from a console that does not have the proper
assignment shall be rejected and an error message shall appear at the console.

Any area of responsibility shall have one or several consoles assigned to it, permitting
more than one operator to control points in that area. In addition, any console could be
assigned to more than one area of responsibility.

C.4.6.2.4. Permissions

To restrict the operator's actions to specific functions, permissions shall be assigned to

each identifier from system level access.

A permission console's assignment shall determine which sets of functions a console

shall have access to and what type of access the console shall have to those sets of
functions.

For example, set of functions shall be:

Dispatching functions,
Supervisory functions,
Generation functions,
Study analysis functions,
Maintenance functions,
Programming functions,
Training functions,
...
 At least, three types of access shall be provided:

Read permission shall allow an operator to view all displays associated with a set
of functions,

Write permission shall allow an operator to enter data into data base using displays
associated with a set of functions,

Execute permission shall allow an operator to execute control from displays

associated with a set of functions.

Several operators may have the same permissions.

If an operator has no permission to access to an application, the displays of this

application shall not be presented to him.

C.4.6.3. General user interactions

C.4.6.3.1. Object selection

Displays shall be used by operator to interact with the system. For this purpose, displays
shall contain elements which can be selected to perform two types of actions:

1. Specific action associated to the selected object,

2. Data entry operations.

1. Selection for specific action.

This selection shall be performed by placing the pointer on the object and pressing a
functional key or track ball button. The specific action shall be executed as soon as
the object is selected. This method shall be used, for example, to call up a pop-up
menu associated to a device, to request an action for the selected device (remote
control, tagging, ...) or to execute a specific program (state estimator ...) associated to
a poke-point.

2. Selection for data entry operations

The data entry operations are described below. This type of selection shall concern
fields and objects in data base.

Four selection techniques shall be provided:

Selecting individual items: By placing the pointer on the item and pressing a
functional key or track ball button,

Selecting a group of items,

 Selecting all items in a window: By setting the window active and pressing a
functional key or track ball button,
 Selecting all items of a display: By setting the window active and pressing a
functional key or track ball button.

In addition of the selection operations, two more basic functions used for data entry
operations shall be provided:

Marking a location in a display used for insert and copy operations,

Cancelling the selection of items before a data entry operation is performed.

C.4.6.3.2. Data entry

Data entry operations shall be available on one-line and tabular displays to modify the
contents of data base.

Four types of data entry operations shall be provided:

1. Entering values into data base fields,

2. Inserting one or more objects in data base,

3. Copying one or more objects from one position to another in data base,

4. Deleting one or more objects from data base.

1. Entering values into data base fields

The method shall be different according to the type of field:

For a boolean field: by placing the pointer on the field and pressing a functional
key or track ball button to toggle (i.e. set or reset) the value,

For numeric or alphanumeric fields: by selecting the field(s) using the techniques
described above and entering data directly into the selected fields. In case of
multiple data entry selection, it shall be possible to move from one field to another
one by pressing specific keys.

2. Inserting one or more objects in data base

This operation shall be possible on tabular displays. This operation shall be

performed by marking a location in the display and inserting selected objects at this
location by pressing a functional key.

3. Copying one or more objects from one position to another in data base

This operation shall be possible on tabular displays. This operation shall be

performed by marking a location in the display and copying selected objects at this
location by pressing a functional key.
 4. Deleting one or more objects from data base

This operation shall be possible on tabular displays. This operation shall be

performed by selecting objects and pressing a functional key to delete them from data
base.

C.4.6.4. Specific operator actions

The following actions shall be available to the operator through the user interface. Whether
the operator shall use display poke points, function keys or others is up to the Vendor. But
in any case, it shall be possible to restrict access to these actions. This shall be done by
using the permissions that the operator has with respect to the data he wants to operate.

C.4.6.4.1. Control procedure

The typical operator control procedure shall involve selecting a point to be controlled,
choosing the direction in which to control it and actually issuing the control command.
The operator shall be able to cancel the sequence at any step before issuing the
execution command.

C.4.6.4.2. Set point procedure

The typical operator set point procedure shall involve selecting a point to be controlled,
entering the expected value for the set point control and actually issuing the control
command. The operator shall be able to cancel the sequence at any step before issuing
the execution command.

C.4.6.4.3. Alarm acknowledgement and inhibition

Alarms that require operator acknowledgement can be acknowledged from any display
showing the source data base object. Individual and multiple objects as well as whole
page display acknowledgements shall be available through a single users action.

It shall be possible to inhibit/enable for alarming, an entire substation, a RTU, or an

individual data base object.

C.4.6.4.4. Measurement in service

It shall be possible to remove/restore from service, an entire substation, a RTU, or an

individual data base object.

Manual measurement entries shall require that the point be removed from service. A
measurement that is not in service shall continue to be scanned, converted to
engineering units and stored with its data quality in the data base.
 C.4.6.4.5. Operator limit entry

Individual limit values shall be enterable on-line by the operator (i.e. manual
thresholds). The entered value shall be checked for validity. When a new limit value is
entered, the associated analogue value shall be checked for any transition into or out of
the violated state with respect to the new limit value.

C.4.6.4.6. Operator value manual entry

Individual digital status points and analogue values shall be enterable from any display
that shows the values. The manual value shall be checked for validity. The value shall
not be accepted if it is considered an illegal state for a digital status point or if it is
unreasonable for an analogue value. When the new value is entered, the digital status or
analogue value shall be checked for any transitions into or out of a violated state
because of the new value.

C.4.6.4.7. Tag placement or removal

The operator shall be able to place, remove or modify tags on the devices of the power
system from any display showing the device. The dialogue shall allow the operator to
choose among all the tag types available in the system.

C.4.6.5. Full display facilities

C.4.6.5.1. Display types

The following display types shall be supported by NCC and TRCC systems:

1. One-line diagrams,
2. Tabular displays,
3. Alarm list displays,
4. Chronological event list display,
5. SOE list display,
6. Summary displays,
7. Telecontrol and telecommunication state display,
8. Intercontrol centre communication display,
9. System configuration displays,
10. Communication statistics display,
11. Tagging displays,
12. Trend displays,
13. Notepad displays,
14. Imported geographical displays.

All displays shall be automatically updated to reflect data changes and to signal events
to the users.
1. One-line diagrams

One-line diagrams shall be manually constructed displays, consisting of graphical

primitives and individually placed graphical objects. Each object shall be placed at
precise location in the display and shall be linked to a data base object. Presentation
of a graphical object shall be user definable. It shall be possible to add condition
that shall make each object alter its presentation depending on the state of the data
base object to which it is linked (see C.4.6.10).

The generation of the various graphic symbols for one-line diagrams shall be
defined during the design stage of the project.

Two types of one-line diagrams shall be provided:

System network overview (showing substations interconnected by the

transmission lines),

Substation one-line diagrams (to control and monitor each substation).

System network overview one-line diagram

This display shall show an overview of the real time state of the network. The
location of plants and substations on this display should follow the geographical
layout of the power system.

The following information shall be displayed on this image:

- electrical node representation,

- active power on lines completed with arrows showing direction of flows,
- total active and reactive production in each power unit and total possible active
generation,
- total active power on transformer per electrical node in each HV / MV
substation.
- voltage per electrical node.

It shall be possible through poke points to call the substation one line diagram from
the network part visible on the operator VDU.

Substation one line diagrams

Each substation one line diagram shall give a substation-specific representation of

the monitored system. Alarmed and unacknowledged telemeasurements and status
telesignals shall be indicated and mechanisms shall be provided for alarm
inhibition, alarm acknowledgement, supervisory control and other functions.
2. Tabular displays

There shall be tabular displays for each substation in addition to the one-line
diagrams. They shall be composed of text and graphic elements. These displays
shall present more detailed information than may fit on a one-line diagram and shall
have the same overall appearance for each substation in the system. These displays
shall be automatically built by the software and reflect the data base content as the
latter is modified.

Typically, tabular displays shall be used for alarm summaries, logs, reports, etc.
Information shall be repeated in either horizontal or vertical direction without size
limitation. To facilitate navigation in these displays, the display shall be divided
into pages and shall include column and row headers that shall appear on every
page.

3. Alarm list displays

Basically, two different kinds of alarm list shall be provided:

- lists showing alarms classified according to their priority level, i.e. A1, A2 and
A3,
- lists showing alarms classified according to their type and origin:

. spontaneous change of state,

. threshold overshoots,
. telecontrol system,
. per substation.

4. Chronological event list display

This list shall contain all the events occurring in power and telecontrol systems in a
chronological order.

5. SOE list display

The SOE list shall display the events time tagged by the RTUs. The SOE event list
shall be identical to the other type of event messages, excepted for the time field
which shall be given with millisecond resolution.

6. Summary displays

The following summary displays shall be provided:

- inhibited points,
- points manually overridden,
- points which are not in their normal state of operation,
- manually removed from service,
- point not in service.
7. Telecontrol and telecommunication state display

This display shall present the status of the SCADA telecontrol and
telecommunication equipment including accessibility of each RTU as well as inter-
site communication paths. From this display, the operator shall be able to modify
the in service status of the communication equipment and the paths.

8. Intercontrol centre communication display

These displays shall be used to initiate communication between control centres and
provide information about related data transfers.

9. System configuration displays

These displays shall show the real time configuration of the data processing system
in the control centre, with the information on the status of all equipment, such as:

- computer operating status,

- operator console status,
- peripheral equipment status,
- UPS status,
- mode of equipment connection.

10. Communication statistics display

This display shall show the communication statistics, such as the count of scan
attempts and errors reported by the data acquisition subsystem for each hour of the
day, accumulated on a monthly basis.

11. Tagging displays

Displays such as tag type definition and tag lists shall be available. From the tag
definition display, the operator shall be able to see the definition of the tag types.
The tag list display shall provide lists of tags currently placed on devices. The
operator shall be able to edit the comments accompanying each tag.

12. Trend displays

These displays shall be completely built by Trend facility (see C.4.6.7.)

13. Notepad displays

Notepad displays shall allow operators to make notes on displays so that they can
communicate information with each other (see C.4.6.8.).
14. Imported geographical displays

It shall be possible to build displays by importing from a GIS (Geographical

Information System) geographical displays in DXF (Drawing interchange or
eXchange Format) standard format. The geographical information could be used as
a background for a general overview of the network, complemented by dynamic
objects in order to monitor and control the network.

C.4.6.5.2. Display rules

C.4.6.5.2.1. Updating of the displayed information

Any information displayed on two or more screens shall be exactly the same. All the
displays shall be updated simultaneously in case of modifications of their contents.
Consequently, all telesignal changes of state, modifications of telemeasurement
values appearing on the screens shall be updated as soon as acquired by the data
processing system.

Single line diagrams and tabular displays

For each TM and TS appearing on single line diagrams and related tabular displays,
the following information shall be indicated using adequate colours and symbols:

- validity,
- manual invalidation,
- automatic invalidation with associated origin (e.g. data acquisition system or state
estimation),
- manual / automatic replacement value.

In particular, automatically invalidated TMs having a manual replacement value shall

be distinguished from manually invalidated TMs having a manual replacement value.

When the replacement values are estimated values, they shall be renewed as soon as
and each time that the state estimator shall be processed.

When a TM is invalid without a replacement value, the corresponding value display

shall be replaced by an asterisk (*), a coloured information or any other symbol.

When a TM overshoots a threshold, the value shall blink until the acknowledgement
of the corresponding alarm.

Calculated values shall be displayed in the same way as telemetered values.

Display of alarms

Alarm occurrence, such as switching device change of state, no voltage on busbar,

threshold overshoot, ..., shall lead to the blinking of related information on images as
long as the operator has not acknowledged the corresponding alarm.

Three alarm markers (i.e. display poke points) associated to each priority level, i.e.
A1, A2 and A3 shall be shown on a particular window. These alarm markers shall
blink when an alarm appears as long as associated acknowledgement is not
performed. A special colour associated to each alarm priority level shall be defined
for the different alarm markers and associated A1, A2 and A3 alarm list messages. It
shall be possible to access to A1, A2 and A3 alarm lists by clicking on the respective
alarm marker.

Display of alarm and event messages in lists

The most recent alarm / event message shall appear on the first relevant list page
which is displayed by default and successive messages shall written underneath one
another.

All information related to the alarm and event lists shall be stored for several days as
specified in sizing requirements paragraph of section C.4.1.

Some information will be able to disappear automatically at the end of the

corresponding event (to be defined at the data base configuration).

All alarm appearance and disappearance shall be displayed in the chronological event
list.

For most of alarms, alarm messages shall disappear from all alarm lists after
acknowledgement of the disappearance of the associated abnormal condition (to be
defined at the data base configuration).

C.4.6.5.2.2. Use of colours

The different colours used to display network element shall be defined as a rule in
accordance with the current practice in Libya.

C.4.6.5.2.3. Screen saver

A screen saver facility shall be provided in each control centre, which allow to blank
automatically the VDU(s)s after that a configurable time has elapsed without any
activity on this VDU(s). This delay shall be individually adjustable for each screen.
Moreover, it shall be possible to activate or not the screen saver facility.

When a VDU has been blanked by the screen saver facility, the displays previously
shown on this VDU shall reappear automatically as soon as data change on these
related displays or any dialogue is engaged by the operators.
C.4.6.5.3. Display navigation

The operator should be able to move quickly and easily between different displays,
using poke-points or menus. Navigation must be simple and self-guiding for the
inexperienced user and powerful (productive and efficient) for the professional expert
user.

MMI system shall support the following navigation mechanisms:

Display directories:

Hierarchical directories of displays shall be available to the operator in order to allow

him to navigate in one of two following ways:
- using a list of tasks: with this approach, the user only needs to know which system
function he wants to perform, and does not need to know the name of the desired
display.
- using a list of displays: in case the user knows the name of the display he wants to
look at.

Menu bars:

It shall be possible to associate a menu bar to a display. The menu bar shall be
located on top of this display, and be composed of various menu items. Upon
selection, each menu bar item shall give access to a pull-down menu.

Pull-down menus:

These menus shall consist in a list of items which either invoke sub-menus or
commands.

Pop-up menus:

These menus shall appear at the cursor location where they are defined in the display.

Pop-up windows:

Pop-up windows shall be separate windows, which are temporarily presented to the
operator, as a means to enter data, send commands and/or provide additional
information.

Poke-points:

It shall be possible to predefine areas that are sensitive to the cursor location in
conjunction with either track ball clicks or keystrokes. Resulting action can be call-
up of a new display or execution of a specific function.
 Paging:

Tabular displays shall support multi-page displays. Use of buttons (page up /page
down) or pull-down menus shall allow rapid positioning to a specific page. The
window title bar shall indicate the current and total page number of the display.

Finding specific display page:

A text entry field accompanied by a dedicated button shall be available to specify the
name of an access key (such as substation name) to allow rapid positioning to the
corresponding page number of a large Tabular display.

Previous display capability:

The MMI system shall retain at least the two previously viewed displays for each
window, not taking into account the paging sequence. A recall function shall cause
these displays to be recalled at the previous level of zoom and decluttering.

C.4.6.5.4. Layers

It shall be possible to define multiple layers in a one-line diagram.

The layering feature shall be useful for hiding data that needs not to be permanently
shown, such as Ampere and MVA calculated values (see paragraph C.4.4.3.4.3).

At least, 16 levels of layers shall be provided. It shall be possible to dynamically set or

reset each layer visibility attribute.

C.4.6.5.5. Panning

The operator must have the ability to smoothly navigate around a very large display by:

- using scroll bars,

- using a mechanism based on the cursor location in the display.

1. Using scroll bars

Scroll bars shall be used to position horizontally or vertically within any large
display.

Scroll bars, applied to any window, shall allow scrolling in one direction as follows:

- with small incremental steps,

- with large incremental steps,

- by grabbing the scroll bar element and position it directly to desired location.
2. Cursor-driven panning

Single step panning and continuous panning are required.

Continuous panning shall perform a move in a series of small steps, in the requested
direction, until stopped by the operator. The speed at which panning is performed,
shall be proportional to the distance separating the track ball cursor from the centre of
the window. It shall be possible to define the panning step on a console basis.
During a continuous panning operation, the display refresh should be kept active.
When a user is moving around a large world-map display, it is suitable to give him
some clear and intuitive indication of the current location of the display portion he
can see. This kind of feedback to the user should also allow quick move when the
state of the system suddenly changes. On operator's request, a small window which
contains a reduced version of the entire display, shall pop up to show the relative
position of the main window over the display. Single step pan action, indicating the
new centre of display on the small window, shall reposition the display accordingly
within the main window.

C.4.6.5.6. Zooming

Any one-line diagram shall have the ability to be magnified or shrunk on demand.

The following procedures are required:

1. Predefined zoom level,

2. Single step zoom,
3. Rubber-band zoom.

1. Predefined zoom level

This procedure shall allow the user to select a predefined zoom level from a menu.

At least, 3 predefined zoom levels shall be provided.

2. Single step zoom

This procedure shall change the size of the display by some increment which
represents the percentage of increase or decrease of a normal size, regardless of its
current size.

It shall be possible to assign zoom factors between 0.1 and 10.

3. Rubber-band zoom

The rubber-band procedure shall allow to select an area in the display and have it
automatically magnified to fit in the window.
 C.4.6.5.7. Decluttering

The ability to have information appear or disappear at different levels of magnification

shall be used as a means of presenting clearer information to the user. The ability to
declutter parts of a display shall be a choice of the user at display definition time.

Zoom and declutter shall be applicable on any layer of a one-line diagram.

C.4.6.6. Printing facilities

C.4.6.6.1. Hardcopy facilities

The capability shall be provided to obtain a variety of hardcopy output:

- hardcopy of the entire screen,

- hardcopy of a display within a window.

The printed display shall reflect the presentation shown on the screen at the time of the
capture, provided that the used printer is a colour printer.

It shall be possible to request an hardcopy of a display not currently viewed in a window

in order to print the entire display.

Hard copy requests shall be buffered, i.e. the NCC and TRCC systems shall store the
displays requested and print them out as soon as the associated hard copy unit is
available.

C.4.6.7. Trending facility

C.4.6.7.1. General requirements

At each control centre (i.e. NCC and TRCC) trending facility shall be provided to allow
the operator to select data from the data bases and send them to display devices for
graphical presentation.

It shall be possible to trend the following data:

- real-time data collected from data bases. This type of data shall be sent to the display
device as it is sampled,
- stored data read from a file and sent to the display device,
- Dispatcher Training Simulator data,
- Post Mortem Review data (see paragraph C.4.4.7.2).

At least, two types of display devices shall be supported:

- VDU of operators workstations for displaying data on a dedicated screen window,

- Strip chart recorders.
It shall be possible to overlay real time, archived and forecasted data trends
simultaneously for comparison purposes. For instance, the operators shall be able to
compare the load flow of past days with the one of the present day and forecasted ones.

C.4.6.7.2. Real time data trending

The real time data requested for trending shall be selected by the operator from full
graphic displays. Any numeric or boolean data from any data base may be selected for
trending. Once selected for trending and assigned to a specific display device, the data
shall be sampled from the relevant data base and sent to the display device (VDU or
strip chart). The sample rate and the display device shall be defined, on a point basis,
using the trending facility user interface.

C.4.6.7.3. Stored data trending

The proposed trending facility shall allow to display stored data on curves for a given
period of time. The different data which can be trended and the associated storage
periods are given respectively in paragraphs C.4.4.7.1 and C.4.1.2.2.3.

C.4.6.7.4. Graphical features

The following features shall be provided.

Drawing areas where curves are presented shall be displayed in a dedicated window.
This window shall support up to 8 areas simultaneously, each of these areas
supporting up to 8 curves simultaneously. Within each drawing area, each curve shall
be displayed using a different colour. The name of each curve shall appear in the
corresponding colour,

The operator shall be given the possibility to modify the graphical presentation of
trended values. The four following presentation types shall be available:

- traces: a basic X-Y plot or graph, similar to the trace of a strip chart recorder,
- bar graphs: one or more points plotted from a common base line,
- pie charts: graphics showing the relative percentage of point values vs. the
"whole",
- meters: graphics showing a point value in relation to a minimum and maximum
scale for a single instance in time.

In addition,

It shall be possible to display curves horizontally or vertically,

An automatic scale adjustment option shall be offered, that adapts the min and max
values to the sampled data. Min and max values shall also be manually enterable,
Scale numbering shall be done in reasonable rounded values (5, 10, 15 ...),
 It shall be possible to define at least two threshold levels (high and low) per sampled
point. Portions of the curve beyond the high level and below the low shall be shaded
in a different colour,
Zooming and scrolling features shall be available,
Designating a point on the curve shall result in displaying accurate Y-axis value
along with time of occurrence,
A print option shall be available in order to print currently displayed trends
(preferably in Postscript format),
A save and restore function may be proposed. This would allow the operator to save
trends of interest in a file and recall them for display (as static data) later on.

C.4.6.8. Operator's notepad

A tool shall allow operators or management staff to make notes on displays so that they
can communicate information with each other. Notes shall be used by the operators as
"yellow post-it" on a display screen flagging something that requires attention.

This tool shall provide ways to capture displays or portion of displays, add text and
graphics, and store the marked-up display as a note.

A note work area shall be available; it shall be a scrollable window that shall provide the
operators drawing primitives (lines, rectangle, circle ...), text, and a colour palette that shall
be used in conjunction with primitives and text.

From the note work area it shall be possible to perform the following:
Select all or portion of a display and paste it into the note,
Add text to the note,
Add graphics to the note,
Move elements in the work area,
Save the note.

It shall be possible to declare a note as being attached to a display. When the display has at
least one note associated with it, a note menu associated to the display shall provide the
following capabilities:
obtain a list of notes: this list shall provide ways to filter the notes according a type of
operator and/or their creation date,
view the display with note attached ( for example highlight rectangle) or not,
move from one note to the next one in the display,
delete notes,
call a note for consultation or modification,
print notes.
C.4.6.9. Report generation system

A report generation tool shall be provided to meet the reporting requirements. For that
purpose, An industry standard commercial Relational Data base Management System
(RDBMS) shall be provided as a means of recording/archiving data (see paragraph
C.4.4.8).

The report generation tool shall provide the capability to automatically and periodically
print reports. Printing may also be requested at any time by the operator.

Calculation functions provided by the report generation tool shall rely on using the
RDBMS capability to the maximum extent. This shall include a means to interactively
define macros involving common calculations (such as min, max, average, standard
deviation, integration, load duration curves, ...) and, either manually or automatically,
trigger user-program execution against archived data for advanced calculation processing.

Data from reports being currently constructed shall stay reachable at least in read-only
mode. The operator shall be given the capability to view report data and possibly modify it.

Data considered as suspect (in terms of data quality) shall be highlighted some way in
reports where they appear. Manually entered/modified data shall be distinguishable as well.

The Tenderer shall organise a comprehensive training related to reports generation in order
that the Owner can customise reports or create new ones, according to his needs.

C.4.6.10. Display editor

The display editor shall be a graphical tool which provides an off-line display building
facility. It shall provide an interactive environment in which users can build graphic
objects and displays, and define the linkage of graphical objects in the displays to the
application data base.

Displays shall be composed of graphical objects that contain both static and dynamic
information linked to a specific class of data base object. Once a graphical object is
defined, instance of this object shall be placed several times on different displays. Displays
shall provide the context in which to view those objects.

The display editing subsystem shall provide the following:

a user interface based on a direct manipulation philosophy. The user's primary means of
interacting with the system shall be by selecting and manipulating visual objects on the
screen instead of typing commands,
the ability to manipulate multi windowing user interface techniques,
 an interactive graphical editor which allows the user to create and modify displays using
direct manipulation. This editor shall allow the user to create and modify libraries of
shared objects and displays. In addition, the user shall be able to create and modify
private objects and symbols,
access to several standard fonts that vary in size, style and boldness,
the ability to create displays and objects regardless of the availability of the data bases
containing the displayed data,
the ability to modify and view displays and objects in an off-line mode which does not
affect the on-line displays,
the possibility to dump display and object definitions into human-readable flat ASCII
files. Once compiled, these files shall be made available to the on-line system.

The display editor shall support the following concepts:

graphic primitives (line, circle, rectangle, arc, ellipse and polygon),

video attributes: it is desirable that these attributes be gathered into a special generic and
reusable type of object. Attribute bundle shall encompass the following items:

- colour,
- blink,
- visibility,
- font identifier,
- line thickness,
- line style,
- fill pattern.

interactors: this kind of objects are used to interact with the user. Interactors supported
shall include:

- menus (pop-up, pull down),

- label/action pairs - labels to be displayed in the menu and the action to occur when that
label is selected.

sensitive area (poke points) that can be bound to a part of an object, an entire object or a
portion of a display. To this sensitive area, one shall be able to associate an action that
shall be executed when the user hits a predefined key,
data entry windows that allow the user to enter data into application data base fields,
function keys/action pairs - although function key are defined at the console level, the
display builder shall be able to redefine the action that results when the user strikes the
key,
scroll bars (horizontal/vertical),
 attribute modifier: these are objects that modify attributes bundles depending on the
result of a test using data fields in the application data base.
Attribute modifiers shall be used to modify the graphic bundles of primitives, formatted
data base fields, scaled primitives.
In addition to use attribute modifier features, the builder shall be able to specify the
visibility of an entire object based on:

. data fields in the application data base,

. console permission assignment.

scaled primitives: the builder shall be able to define primitives that are scaled according
to user specified values. These values can be data base fields or constants. Whenever the
value is a data base field, the primitive shall be dynamically scaled as the value changes.

When editing displays, the operator shall be able to specify:

static background information,

one line type display where each object in the display shall be placed and linked to a
data base object using a record key,
or tabular display for which the operator shall be able to specify particular portions of
the data base record to be used.

At any point in the display editing process, if the data base exists, the user can request a
compilation of the display and a check of the link to the data base objects.

Once compiled, the display can be brought on-line.

HMI

- HMI is one sub-system of the whole SCADA system.
- Consists of some tools simplify user work on machine (User friendly interface.
- Consistes of menues displays and functions help to monitor and control the grid.
- Can be thought as a dynamic database that get the static database (objects) from database sub-system
and
put real-time data from data sub-system on it to display it to the operator.

All the best,

Any question, please do not hesitate.