MicroSCADA Pro SYS 600 9.

3
System Configuration
1MRS756646 MicroSCADA Pro SYS 600 9.3
Issued: 31.3.2010
Version: B/31.12.2010 System Configuration

Contents:

1. Copyrights ............................................................................................... 9
2. Introduction ........................................................................................... 10

2.1. This manual ................................................................................. 10

2.2. Use of symbols ............................................................................ 10
2.3. Intended audience ....................................................................... 11
2.4. Product documentation ................................................................ 11
2.5. Document conventions ................................................................ 12
2.6. Document revisions ..................................................................... 12
3. Functional overview of SYS 600 ......................................................... 13

3.1. System architecture ..................................................................... 13

3.2. System server .............................................................................. 14
3.2.1. Application examples .................................................... 15
3.2.2. System objects .............................................................. 16
3.2.3. Application objects ........................................................ 17
3.2.4. Programming language SCIL ........................................ 17
3.2.5. Process database ......................................................... 17
3.2.6. Report database ........................................................... 17
3.3. Process communication ............................................................... 18
3.3.1. Communication servers ................................................ 18
3.4. Communication gateway .............................................................. 19
3.5. Workplaces .................................................................................. 19
3.6. Peripheral equipment ................................................................... 20
3.6.1. Printers .......................................................................... 20
3.6.2. Alarm annunciation units ............................................... 20
3.6.3. GPS clocks .................................................................... 21
3.6.4. Service modems ........................................................... 21
3.7. System Self Supervision .............................................................. 21
3.8. Event handling ............................................................................. 21
3.8.1. Data collection .............................................................. 21
3.8.2. Time tagging ................................................................. 22
3.8.3. Event criteria and actions .............................................. 22
3.8.4. Event descriptions ......................................................... 22
3.8.5. Event logging ................................................................ 23
3.8.6. Event post-processing .................................................. 23
3.8.7. Event display ................................................................. 23
3.9. Alarm handling ............................................................................. 24
3.9.1. Alarm ............................................................................. 24
3.9.2. Alarm indication ............................................................ 24
3.9.3. Alarm display ................................................................ 24
3.10. Reporting ..................................................................................... 25
3.10.1. Data logging .................................................................. 25
3.10.2. Data processing ............................................................ 26
3.10.3. Trends ........................................................................... 26

3
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

3.10.4. Measurement reports .................................................... 26

3.10.5. Localization ................................................................... 27
3.11. Time synchronization ................................................................... 27
3.11.1. GPS ............................................................................... 27
3.11.2. DCF77 ........................................................................... 29
3.12. Redundancy ................................................................................. 29
3.12.1. Server redundancy ........................................................ 29
3.12.2. Communication redundancy ......................................... 30
3.13. Mirroring ....................................................................................... 30
3.14. OPC connectivity ......................................................................... 31
3.15. Capacity and performance scalability .......................................... 32
3.15.1. Computer capacity ........................................................ 32
3.15.2. Distributing processing capacity ................................... 32
3.16. Product licensing .......................................................................... 33
4. Configuration ........................................................................................ 35

4.1. Configuring system server ........................................................... 35

4.1.1. Hardware and operating system ................................... 37
4.1.2. Base system (SYS) ....................................................... 37
4.1.2.1. Base system objects .................................. 37
4.1.2.2. Memory configuration ................................. 52
4.1.3. Applications (APL) ........................................................ 55
4.1.3.1. Configuring APL objects ............................. 56
4.1.3.2. Mapping devices ........................................ 56
4.1.3.3. Adding applications .................................... 57
4.1.3.4. Removing applications ............................... 58
4.1.4. Configuring license protection ....................................... 58
4.2. Configuring workplaces ................................................................ 58
4.2.1. Windows terminal server ............................................... 59
4.2.2. Citrix MetaFrame Application Server ............................ 62
4.2.2.1. Verifying client connections ........................ 62
4.2.3. Defining MON objects ................................................... 64
4.2.4. Monitor Pro configuration .............................................. 67
4.2.4.1. OpenRemoteDesktop ................................. 71
4.2.4.2. Configuring RDP session ........................... 81
4.3. Configuring process communication ............................................ 84
4.3.1. Configuring communication system objects in base
system ........................................................................... 84
4.3.2. Configuring process communication units .................... 86
4.3.2.1. Configuring PC-NET ................................... 86
4.3.2.2. Configuring IEC 61850 with External OPC
DA Client .................................................... 92
4.3.2.3. Configuring CDC-II slave ............................ 92
4.3.2.4. Configuring Modbus slave .......................... 92
4.3.2.5. Configuring CPI-connected applications .... 93
4.3.2.6. Selected configuration examples for
PC-NET ...................................................... 93

4
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

4.3.3. Distributed process communication units ................... 109

4.3.3.1. Distributed PC-NETs ................................ 109
4.4. Configuring System Self Supervision ........................................ 112
4.5. Configuring communication gateway ......................................... 113
4.5.1. SYS_BASCON.COM modifications ............................ 114
4.5.2. Gateway license .......................................................... 114
4.6. Configuring peripheral equipment .............................................. 114
4.6.1. Configuring printers ..................................................... 115
4.6.1.1. LAN connection ........................................ 115
4.6.1.2. NET connection ........................................ 115
4.6.2. Configuring I/O adapter cards ..................................... 118
4.7. Configuring time handling .......................................................... 121
4.7.1. Configuring time synchronization ................................ 121
4.7.1.1. Configuring external clocks ...................... 122
4.7.2. Configuring time zone and daylight saving ................. 123
4.7.3. Time zone and daylight saving history ........................ 124
4.7.4. Configuring representation of dates ............................ 124
4.8. Configuring networks ................................................................. 126
4.8.1. Configuring Local Area Networks (LAN) ..................... 129
4.8.2. Communicating between applications ........................ 130
4.8.2.1. Local applications ..................................... 130
4.8.2.2. Applications in separate base systems .... 132
4.9. Configuring redundancy ............................................................. 134
4.9.1. Hot stand-by base systems ......................................... 134
4.9.1.1. Functional description .............................. 134
4.9.1.2. Configuring hot stand-by systems ............ 135
4.9.1.3. SYS_BASCON.COM in hot stand-by
systems .................................................... 136
4.9.1.4. Watchdog application ............................... 138
4.9.1.5. Shadowing ................................................ 140
4.9.2. Hot stand-by with OPC client and servers .................. 140
4.9.2.1. Starting an External OPC Data Access
Client ........................................................ 141
4.9.2.2. Activating station communication ............. 141
4.9.3. Hot stand-by with PC-NET .......................................... 142
4.9.3.1. PC-NET configuration .............................. 142
4.9.3.2. Activating communication ......................... 143
4.9.3.3. Deactivating communication .................... 144
4.9.4. Hot stand-by with CDC-II slave ................................... 145
4.9.5. Hot stand-by with Modbus slave ................................. 145
4.9.5.1. Modbus slave configuration ...................... 145
4.9.5.2. Activating communication ......................... 147
4.9.5.3. Deactivating communication ................... 147
4.9.6. Hot stand-by with CPI applications ............................. 148
4.9.7. Hot stand-by with communication gateway COM
500i ............................................................................. 149
4.9.7.1. Configuring communication gateway COM
500i .......................................................... 150
5
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

4.10. Configuring mirroring ................................................................. 152

4.10.1. Station mapping .......................................................... 153
4.10.2. Process messages ...................................................... 154
4.10.3. Process commands .................................................... 154
4.10.4. System object (STA:S) communication ....................... 155
4.10.5. System messages ....................................................... 155
4.10.6. Subscriptions .............................................................. 156
4.10.7. Buffering and communication breaks .......................... 156
4.10.8. Hot stand-by ................................................................ 158
4.10.9. Disabling mirroring ...................................................... 158
4.10.10. Application events ....................................................... 159
4.10.11. Configuration examples .............................................. 161
4.10.11.1. Example 1: One host, one image ............. 162
4.10.11.2. Example 2: Two hosts, redundant
image ........................................................ 164
4.10.11.3. Example 3: Station numbering convention in
a mirroring system .................................... 167
4.10.11.4. Example 4: Local mirroring ....................... 170
4.10.11.5. Example 5: Hierarchical mirroring ............ 171
4.11. Configuring OPC connectivity .................................................... 173
4.11.1. DCOM settings ............................................................ 173
4.11.1.1. Enabling of Distributed COM .................... 174
4.11.1.2. Defining access permissions .................... 174
4.11.1.3. Defining launch and activation
permissions .............................................. 175
4.11.1.4. Defining DCOM settings for OPC
servers ...................................................... 175
4.11.1.5. Defining DCOM settings for OPC Server
Enumerator ............................................... 175
4.11.2. Local Security Policy settings ..................................... 176
4.12. Configuring Process Display Note links ..................................... 176
4.13. Icon storage and configuration .................................................. 177
4.13.1. Customizing icon mappings ........................................ 178
4.14. Configuring Customize Search dialog ....................................... 178
4.15. Changing Login and About Monitor Pro dialog graphics ........... 180
4.16. Configuring login dialog shortcut key ......................................... 180
5. Configuration tools ............................................................................. 181

5.1. System Configuration Wizard .................................................... 181

5.2. Configuring single base system ................................................. 181
5.3. Configuring hot stand-by base system ...................................... 184
5.4. System Configuration Tool ......................................................... 188
5.4.1. Starting System Configuration Tool ............................. 189
5.4.2. Handling objects and attributes ................................... 190
5.4.2.1. NET Node station address ....................... 192
5.4.3. Saving configurations .................................................. 192
5.4.4. Creating a new configuration ...................................... 192

6
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

5.4.4.1. Adding new objects .................................. 193

5.4.4.2. Deleting objects ........................................ 195
5.4.4.3. Adding a redundant line ........................... 195
5.4.4.4. Deleting a redundant line ......................... 196
5.4.5. Configuring dial-up ...................................................... 197
5.4.6. Station redundancy ..................................................... 198
5.4.6.1. Configuring primary and secondary
stations ..................................................... 198
5.4.6.2. Adding a proxy STA object ....................... 199
5.4.7. Configuring IEC 61850 ................................................ 200
5.4.8. Saving as a default configuration ................................ 201
5.4.9. Online configuration .................................................... 202
5.4.9.1. Loading online configuration .................... 202
5.4.9.2. Saving online configuration ...................... 204
5.4.10. Taking configuration in use and out of use .................. 205
5.4.11. Reallocating stations ................................................... 206
5.4.11.1. Cutting and copying stations .................... 206
5.4.11.2. Pasting stations ........................................ 207
5.4.12. Previewing .................................................................. 208
5.4.13. User-defined programs ............................................... 208
5.4.14. Sending general object handling command ................ 210
5.4.15. Defining general environment definitions .................... 211
5.4.16. System monitoring ...................................................... 211
5.4.16.1. Supervision log ......................................... 213
5.4.16.2. Supervision Filter Editor ........................... 214
5.4.17. Signal engineering ...................................................... 215
5.4.17.1. Indicator for signal information ................. 215
5.4.17.2. REX, LMK and SPA stations .................... 217
5.4.17.3. Topic configuration for PLC stations ......... 217
5.4.17.4. Configuring data points for DNP
stations ..................................................... 220
5.4.17.5. Configuring memory areas for STA
stations ..................................................... 222
5.5. Base System Object Navigator .................................................. 225
5.6. Communication Engineering tool ............................................... 226
5.6.1. Building an object tree ................................................ 226
5.6.2. Configuring objects ..................................................... 226
5.6.3. Using object tools ........................................................ 226

7
8
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

1. Copyrights
The information in this document is subject to change without notice and should not be
construed as a commitment by ABB Oy. ABB Oy assumes no responsibility for any
errors that may appear in this document.

In no event shall ABB Oy be liable for direct, indirect, special, incidental or consequential
damages of any nature or kind arising from the use of this document, nor shall ABB Oy
be liable for incidental or consequential damages arising from use of any software or
hardware described in this document.

This document and parts thereof must not be reproduced or copied without written per-
mission from ABB Oy, and the contents thereof must not be imparted to a third party
nor used for any unauthorized purpose.

The software or hardware described in this document is furnished under a license and
may be used, copied, or disclosed only in accordance with the terms of such license.

© Copyright 2010 ABB. All rights reserved.

Trademarks

ABB is a registered trademark of ABB Group. All other brand or product names men-
tioned in this document may be trademarks or registered trademarks of their respective
holders.

Guarantee

Please inquire about the terms of guarantee from your nearest ABB representative.

9
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

2. Introduction

2.1. This manual

This manual provides thorough information on the SYS 600 software and hardware
installation: base systems, LAN connections, process communication systems, workplaces
and peripherals.

This manual provides thorough information on the various configuration settings that
you have to make in order to use your SYS 600 system. The manual also describes how
to use the configuration tools.

The rows in some of the SCIL examples in this manual have

been split to two rows. Take this into consideration when
copying the SCIL examples.

2.2. Use of symbols

This publication includes the following icons that point out safety-related conditions or
other important information:

The warning icon indicates the presence of a hazard which

could result in personal injury.

The caution icon indicates important information or warning

related to the concept discussed in the text. It might indicate
the presence of a hazard which could result in corruption of
software or damage to equipment or property.

The information icon alerts the reader to relevant facts and

conditions.

It should be understood that operation of damaged equipment could, under certain

operational conditions, result in degraded process performance leading to information
or property loss. Therefore, comply fully with all notices.

10
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

2.3. Intended audience

This manual is intended for engineers to support configuration and engineering of systems
and/or applications.

2.4. Product documentation

Name of the document Document ID

SYS 600 9.3 Application Design 1MRS756637

SYS 600 9.3 Process Display Design 1MRS756636
SYS 600 9.3 Communication Programming 1MRS756651
Interface (CPI)
SYS 600 9.3 System Objects 1MRS756662
SYS 600 9.3 Application Objects 1MRS756660
SYS 600 9.3 Status Codes 1MRS756663
SYS 600 9.3 Visual SCIL Application Design 1MRS756645
SYS 600 9.3 Programming Language SCIL 1MRS756661
SYS 600 9.3 Visual SCIL Objects 1MRS756652
SYS 600 9.3 CDC-II Slave Protocol 1MRS756649
SYS 600 9.3 OPC Server 1MRS756659
SYS 600 9.3 External OPC Data Access Client 1MRS756647
SYS 600 9.3 IEC 60870-5-101 Slave Protocol 1MRS756653
SYS 600 9.3 IEC 60870-5-104 Slave Protocol 1MRS756654
SYS 600 9.3 IEC 61850 System Design 1MRS756664
SYS 600 9.3 IEC 61850 Master Protocol (OPC) 1MRS756632
SYS 600 9.3 Modbus Slave Protocol 1MRS756642
SPA-ZC 400, SPA to IEC 61850 Gateway, 1MRS755347
Installation and Commissioning Manual
LIB 500 *4.2. Operation Manual 1MRS755359
RER 111 Technical Reference Manual 1MRS750104-MUM

Other related documents:

• Microsoft Windows Server 2003 Terminal Server licensing manual

• MMC500_TS.CMD in the Microsoft Windows Server 2003 Terminal Server
installation Manual

11
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

2.5. Document conventions

The following conventions are used for the presentation of material:

• The words in names of screen elements (for example, the title in the title bar of a
dialog, the label for a field of a dialog box) are initially capitalized.
• Capital letters are used for file names.
• Capital letters are used for the name of a keyboard key if it is labeled on the keyboard.
For example, press the CTRL key. Although the Enter and Shift keys are not labeled
they are written in capital letters, e.g. press ENTER.
• Lowercase letters are used for the name of a keyboard key that is not labeled on the
keyboard. For example, the space bar, comma key and so on.
• Press CTRL+C indicates that you must hold down the CTRL key while pressing
the C key (to copy a selected object in this case).
• Press ALT E C indicates that you press and release each key in sequence (to copy
a selected object in this case).
• The names of push and toggle buttons are boldfaced. For example, click OK.
• The names of menus and menu items are boldfaced. For example, the File menu.
• The following convention is used for menu operations: Menu Name > Menu Item
> Cascaded Menu Item. For example: select File > Open > New Project.
• The Start menu name always refers to the Start menu on the Windows Task Bar.
• System prompts/messages and user responses/input are shown in the Courier font.
For example, if you enter a value out of range, the following message is displayed:
Entered value is not valid.
You may be told to enter the string MIF349 in a field. The string is shown as follows
in the procedure: MIF349
• Variables are shown using lowercase letters: sequence name

2.6. Document revisions

Version Software revision Date History

number

A 9.3 31.3.2010 New document

B 9.3 FP1 31.12.2010 Document updated

12
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

3. Functional overview of SYS 600

MicroSCADA Pro Control System SYS 600 is a modular and scalable automation
product. It is structured into a generic application independent platform and application
functionality. SYS 600 is designed mainly for Substation Automation and Network
Control applications. It scales from compact single computer communication gateway
or monitoring applications in substations to hierarchical and redundant network control
systems, managing tens to several hundreds of thousands of data points. One of the
strengths of the system is the scalability regarding capacity and performance but also
regarding functionality. This enables a suitable solution for every need.

3.1. System architecture

The main components of a SYS 600 system are:

• System servers
• Communication servers
• Workstations
• Peripheral equipment including printers, GPS clocks, alarm devices
• Communication equipment including switches, routers, modems
• IEDs, process devices, data acquisition units, RTU’s, PLC’s and so on

The different system components can be used to build everything including the following:

• A small single computer monitoring system, for example, embedded in a panel PC

with touch screen mounted in the door of a cubicle (as shown in Figure 3.1-1)
• A hierarchical system in several levels with redundant servers (as shown in Fig-
ure 3.1-2)

A070742

Figure 3.1-1 Single computer system in Panel-PC with touch screen

13
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

A070743

Figure 3.1-2 Interconnected systems in several levels

3.2. System server

Most of the different functions in SYS 600 are handled by the system server. In each
system server, there is one base system that is responsible for the central data processing
services. Each base system can include one or several applications, as shown in Figure 3.2-
1. The application defines the automation functionality and user interface, by its own
real-time process database, history database, displays and so on. The applications are
independent from each other, although they can interact with each other. A typical single
computer SA system has one system server with one base system and one application,
whereas a large distributed control system can have several servers with several applic-
ations each. The applications can be divided according to:

• application area (for example, electricity or district heating)

• tasks (for example, reporting, process display handling, communication gateway)

14
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

A070744

Figure 3.2-1 System Server Architecture

The system server can also include the communication services needed for the remote
communication (communication with an upper level system) and the process communic-
ation (communication with the process or lower level systems). However, these services
can also be located in separate communication servers.

The system server also supports redundancy by a hot stand-by concept for the applications,
and with the help of it the availability of the system can be improved.

3.2.1. Application examples

Application examples are shown in the following figures:

A070745

Figure 3.2.1-1 System with one system server including all functionality

15
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

A071116

Figure 3.2.1-2 System with several system servers for various tasks

A071117

Figure 3.2.1-3 System with hot stand-by servers

3.2.2. System objects

The components of the system and the system server is configured and managed by
means of System objects. There is a system object for each connected station (IEDs,
RTUs and so on), printer, system node (base system, PC-NET, OPC servers and so on)
and application. The most important system object types are listed below:

• System
• Application
• Link
• Node
• Station
• Printer
• Monitor

The system objects have a number of attributes that are use for configuring and monitoring
of the system. The system objects are created and managed by SCIL.

For more information, see SYS 600 System Objects.

16
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

3.2.3. Application objects

Each application contains a number of various application objects. The application objects
define the behavior of the application. The application object types are listed below:

• Process objects (and free type process objects)

• Event handling objects
• Scales
• Time channels
• Event channels
• Command procedures
• Data objects

For more information, see SYS 600 Application Objects.

3.2.4. Programming language SCIL

The script programming language SCIL plays a central role in the SYS 600 system. All
objects, both system and application, are created and managed by SCIL. In addition to
that, all supervision and control tasks are executed by SCIL programs. Most of the con-
figuration and engineering tasks are managed by tools whereby the SCIL program is
hidden for the user. Also the SCIL, in the supervision and control tasks, are by default
hidden from the user. But in case the functionality needs to be customized and extended,
it can be accomplished by SCIL. SCIL can also be used to develop new user interface
applications and dialogs.

For more information, see SYS 600 Programming Language SCIL, SYS 600 Visual
SCIL Application Design and SYS 600 Visual SCIL Objects.

3.2.5. Process database

The process database is the storage for all process data related application objects. These
are process objects, scales, event handling objects and free type process objects. The
process database is a high performance and high capacity real time database that is
maintenance free and can be configured online. The objects are created, deleted and
managed with SCIL and with dedicated tools.

For more information, see SYS 600 Application Objects.

3.2.6. Report database

The report database is the storage for all reporting, calculation and data processing related
application objects. These objects are: Time channels, Event channels, Command pro-
cedures and Data objects.

17
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

For more information, see SYS 600 Application Objects.

3.3. Process communication

The task of the process communication is to form a communication link between the
SYS 600 system server and various process devices, like IEDs, RTUs, PLC and so on.
The communication with the process devices uses various types of protocols like IEC
60870-5-10x, IEC 61850, DNP, Modbus, LON, SPA and so on. Each protocol has its
own characteristics and the physical media and interfaces have to be built accordingly.
The software interface in SYS 600 is handled by a communication unit. The communic-
ation unit is dependent on the protocol that is used.

The most common communication units are the PC-NET and the IEC 61850 OPC
Server/External OPC DA Client. The PC-NET is used with most of the SYS 600 protocols,
except IEC 61850, which is handled by the IEC 61850 OPC Server and the External
OPC DA Client. The process communication can be integrated in the system server in
compact systems and it can also be allocated to dedicated communication servers.

For the process communication, always use shielded commu-

nication cables to minimize the effect of electrical disturbances
to the communication lines connected to SYS 600. The max-
imum shield is provided, when the shield of the communica-
tion cable has been wired to the DB9 connectors in both ends.
The additional equipments, for example, gender changers or
DB9 adaptors, should not be used together with serial cables.

3.3.1. Communication servers

The communication services can be allocated to dedicated communication servers. This

can be done under the following circumstances:

• When higher capacity and performance is needed than what one server with
everything integrated can handle
• When more hardware interfaces are needed, for example, serial ports or LON
interfaces
• To minimize impact of hardware failure
• When redundant communication servers are required

The communication server typically communicates with the systems server over LAN.

The communication server always includes one or several communication units (PC-
NET, IEC 61850 OPC Server); but it can also be configured to include its own process
database. When it includes its own process database, it communicates with the system
server(s) by means of the process data mirroring function. The reasons for including the
process database could be one of the following:

18
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

• The communication server provides data to several system servers

• Higher buffering capacity of the data between the communication server and the
system server is needed
• Local data processing in the communication server is required

The communication servers can be implemented both as a single computer and as a hot
stand-by pair.

The components of the communication server vary depending on the used protocols and
on the overall system architecture. The most important components are:

• PC-NET
It includes protocol drivers for all supported protocols, except IEC 61850 (and those
implemented with CPI).
• SYS 600 base system
• IEC 61850 OPC Server
It is an IEC 61850 client that is connected to SYS 600 base system over OPC.
• External OPC DA Client
The OPC DA Client that is used to connect the IEC 61850 OPC Server to the base
system.

3.4. Communication gateway

The communication gateway is a system server with an application, that routes messages
from the process communication to the remote communication and vice versa. The
gateway application is called COM 500i. The communication gateway can have the
communication services integrated in it or can also use external communication servers
for process communication. It can be configured in hot stand-by mode. The application
can be freely combined with any other system server functionality including reporting,
process displays and IED tools.

3.5. Workplaces
The workplace provides the means for the operator to configure the system, and at the
same time, supervise and interact with the process with the help of the graphical user
interface (GUI). The workplace is always connected to a system server. Each system
server can have its local workplace but the workplaces can also be distributed to other
computers and locations. The computer, in which the workplace is used, is called work-
station. The system supports two different types of workplaces: the classic workplace
and the pro workplace. The classic workplace refers to the workplace technology used
in earlier versions of the product, while the pro workplace refers to the workplace concept
introduced with SYS 600 9.x. The classic workplace is supported to provide full compat-
ibility and easy migration from older product versions to newer.

Each system server can have up to 50 pro workplaces and/or 100 classic workplaces
simultaneously in use.

19
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

The workstations can be distributed over a network using TCP/IP. It can be a LAN,
internet or mobile wireless communication.

Each workplace can be used for engineering, supervision and operation of the process.
The possibilities are defined by the access rights given to the user in question. Also the
layout and functions of the workplaces can be fully customized for each user.

The distributed classic workplace is based on the X-window technique and uses the
Exceed X-server emulator in the workstation. The pro workplace concept is based on
available remote access techniques, typically Microsoft’s Terminal Server or Citrix
Access Essentials. Any PC or other web enabled device can hence be used as a worksta-
tion without installing any additional software.

3.6. Peripheral equipment

Various peripheral equipment can be connected to the system. The most typical ones are
listed below:

• Printers
• Alarm annunciation units
• GPS clocks
• Service modems

3.6.1. Printers

The printers can be connected to the system server either directly, over a LAN via printer
servers, or via the process communication system.

A base system can have up to 20 printers of different types: it can be a matrix printer,
or a laser printer. Printers can be allocated for different tasks, including alarm and event
printout, hard copy, and historical reports. It can be programmed to take over the tasks
of another printer automatically.

Printouts can be produced automatically or manually. The layout of a printout can be

customized. The main printout types are logs, reports, hard copies and documents. Logs
are automatic printouts based on process events. The logs can be directed to one or more
printers.

3.6.2. Alarm annunciation units

Alarm annunciation units can be connected to the system to produce visual or audible
alarms and a provision to acknowledge alarms. Some units can also supervise the system
server and produce alarms in the case of failure.

20
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

3.6.3. GPS clocks

For accurate time synchronization, one or several GPS clocks can be connected to the
system. The clock can be connected directly over LAN, using standard Operating System
functions, or it can be connected via the process communication bus, for example, over
IEC 61850.

3.6.4. Service modems

A possible service modem can be connected to the system. This can provide remote
access to the system, for example, over the public telephone network. The remote access
can be used for monitoring, fault analysis and maintenance of the system.

3.7. System Self Supervision

The System Self Supervision function shows the status of the various system components
in a display for easy and fast system maintenance and fault localization. The display
shows information about the base system, applications, redundancy, communication
lines, IEDs and so on. The system can also receive status information from any device
or external software reporting to the Windows event log, for example, disks, power
supplies and computer boards. Communication equipment and peripheral devices that
support SNMP can also be supervised by using a SNMP-OPC gateway.

3.8. Event handling

An event is a kind of change in the process or in the system, that occurs at a certain
moment in time. Event can be caused by changes in the process, actions performed by
the user, faults in the system and so on.

3.8.1. Data collection

All data related to the controlled process, including status indications, measurements
and commands, are managed by the process database. In addition to these, data related
to the system itself, connected IEDs, RTUs, peripheral equipment, user activities and so
on can be collected into the process database. Each signal is represented by a process
object in the database.

In addition to the object value, the process object holds a number of attributes that gives
more information about the value, as well as describes how events are generated based
on changes in the process object.

21
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

3.8.2. Time tagging

Each process object has a time tag that tells when the object was updated. The time tag
typically originates from the source of the data, for example, IED, RTU, and so on. Only
if the device, that collects the data, does not support time tags, or if the used communic-
ation protocol does not support time tags, then the system itself gives the time tag. The
time tag resolution is 1 ms, but the accuracy depends on the time accuracy of the data
source.

3.8.3. Event criteria and actions

For each process object, it is possible to specify what kind of actions take place and
when. Examples of these criteria and actions are listed below:

• Criteria
• New value
• Updated value
• Value goes up/down
• Warning state reached
• Alarm state reached
• Alarm acknowledged
• Actions
• Event logging
• Activation of freely configurable post-processing
• The freely configurable post-processing can basically initiate any type of
activity in the system
• Printouts

3.8.4. Event descriptions

The system also contains descriptive information about each event. This information is
shown in the event list. The descriptive information can be formed from two different
texts: the state text and the message text.

The state text described the current object state and is dependent on the object value.
The state text can however also take into account any other attribute of the process object
in order to exactly describe the situation.

The message text is formed based on the object value transition, both the old value and
the new value.

The event descriptions are defined by event handling objects in the process database.
Each process object is associated with an event handling object.

22
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

3.8.5. Event logging

All events, that are defined to be logged, are stored in an event database. The capacity
of the event database is only limited by the disk storage capacity. Most process object
attributes are stored with each event to enable exact post-analysis of the process state.

3.8.6. Event post-processing

It is possible to initiate some post-processing at an event. The post-processing is imple-

mented by a SCIL program, that can perform any type of tasks, including reading a dis-
turbance record file from an IED, starting a command sequence, sending data to another
system and starting an external program.

3.8.7. Event display

The event display shows events stored in the event database, as shown in Figure 3.8.7-
1. It supports easy sorting and filtering of the events to make the event analysis as easy
as possible. It can also be freely configured to display the information, the layout and
colouring of the events.

It is also possible to have predefined filters that are easily accessed from toolbars and
menus.

A060788

Figure 3.8.7-1 Event display

23
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

3.9. Alarm handling

3.9.1. Alarm

An alarm is a state of a signal, (process object) that is so critical that it is defined to cause
special actions in the system in order to notify the operator. Some alarms require an
acknowledgement. An alarm can have the following states:

• Active (or persisting)

• The alarm state is active but the alarm does not need to be acknowledged
• Active unacknowledged
• The alarm state is active but not yet acknowledged
• Active acknowledged
• The alarm state is active and acknowledged
• Fleeting
• The alarm state is no longer active but has not been acknowledged after it
became active

The state transitions of an alarm can cause an event in the system, as well as the
acknowledgements. In this way, it is possible to analyze the alarm state history with the
help of the event display. With proper filtering, the event list can show all alarm activa-
tions, deactivations and acknowledgements.

3.9.2. Alarm indication

Alarming signals are represented in various ways in the system. The alarm state
information is always available in the process database and can be used for any type of
alarm representation. The most typical signals are listed below:

• A specific representation in the process display, for example, a blinking symbol

• The signal representation is colored red, for example, in process displays, lists,
dialogs and so on
• An audio signal is played, for example, a horn or sound file of the computer
• The alarm is displayed in the alarm display
• The alarm is displayed in the object dialog of the concerned object

3.9.3. Alarm display

The alarm display shows the alarms of the system in a list, as shown in Figure 3.9.3-1.
It supports easy sorting and filtering of the events to make the alarm analysis as easy as
possible. It can also be freely configured to display the information, the layout and col-
oring of the alarms.

It is also possible to have predefined filters that can be easily accessed from toolbars and
menus.

24
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

A070030

Figure 3.9.3-1 Alarm display

3.10. Reporting

3.10.1. Data logging

Data, that needs to be stored in the system, is stored in data objects. Each data object
can hold between 1 and 1 000 000 data entries of the data types: real, integer, text and
time. One data object can hold data of one data type only. The total number of data
objects and Command Procedures is 1 000 000. So the maximum number of data entries
is 1012 (can further be restricted by the license). If more data needs to be logged and
stored an external history database has to be used. HIS 600 is an example of such database.

The data logging can be triggered based on the time (at certain time intervals), based on
events, or at any time from a SCIL Program. The raw value for the data logging, which
is defined in the data object as a SCIL expression, is typically taken from a process object
(a current or voltage measurement). But it can also be derived from several process
objects or other system data, including mathematical formulas. Before the actual value
is logged, an additional formula that operates on the new value and the already logged
values, can be applied in order to calculate sums, mean values, integral values, differences,
derivative values, maximum and minimum values. Additional refinement of the logged
data can be achieved by SCIL programming.

25
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

Each data object entry has a time tag and status information. The status information is
derived from the source for the data. For example, if a process object that is used as a
source for the logging has uncertain status, also the data object entry gets the uncertain
status. The time tag is the time when the logging occurred.

3.10.2. Data processing

All data objects are fully accessible with SCIL so further data processing can be achieved
by SCIL programming. In this way, further data analysis and refinement can be achieved
to calculate forecasts, trends, various statistics and so on. The result of the calculations
can also be stored in data objects for visualization or other needs.

3.10.3. Trends

The trend display is an application that collects data and visualizes the data in numerical
or graphical form. It is used for follow up and analysis of data in time frames from
minutes to one month. The data is logged cyclically in intervals of 30 seconds, 1, 2, 5
or 10 minutes. The trend display can log and show any type of data available in the
process database.

3.10.4. Measurement reports

The measurement reports display is also an application that collects data and visualizes
the data in numerical or graphical form. The measurement reports display is used to log
and report data during longer periods than the Trend Application, and it is dedicated for
Energy, Current, Voltage, Temperature and Frequency reports. The available time ranges
for the reports are listed below:

• Hourly report (time resolution: 1, 2, 3, 5, 6, 10, 15, 20 or 30 minutes)

• Daily report (time resolution: 15 minutes)
• Daily report (time resolution: 30 minutes)
• Daily report (time resolution: 60 minutes)
• Weekly report (time resolution: 1 day)
• Monthly report (time resolution: 1 day)
• Yearly report (time resolution: 1 month)

The storage period for the reports can be up to 5 years. Longer storage periods can be
custom built or achieved by exporting data to an external reporting database.

26
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

A071350

Figure 3.10.4-1 Measurement reports display

3.10.5. Localization

It is possible to translate the user interface to any language that can fit into the boundaries
of the graphical user interface, that is, size, position and direction of texts and icons. The
system also supports several languages simultaneously enabling operators to work with
the system in his native language. The language is part of the user profile and is selected
automatically while login to the system.

3.11. Time synchronization

3.11.1. GPS

The GPS time can be used to synchronize the computer in various ways; the most common
ways are listed below:

• LAN
• Serial Port
• Dedicated PC Card

When the GPS clock is connected to the LAN, it communicates with the SYS 600 com-
puter using SNTP (Simple Network Time Protocol). The SNTP is needed, as there is a
SNTP client in the computer that synchronizes the internal clock. If IEC 61850 is used
in the system, the IEC 61850 client can also act as a SNTP client. If IEC 61850 is not

27
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

used, an external SNTP client has to be used. Alternatives are Tardis2000, Yats32 Syn-
chronization applications and Trimble Ace III.

It is preferable to connect the GPS over LAN in IEC 61850

systems, because then the same clock can be used to synchron-
ize the IEDs.

The GPS clock can also be connected to a serial port of the computer. In this case the
clock manufacturer provides driver that handles the synchronization of the computer
clock. One example is Meinberg GPS 167, as shown in Figure 3.11.1-1.

A070485

Figure 3.11.1-1 Meinberg GPS 167

The GPS signal can also be handled by a dedicated PC Card. Also in this case the man-
ufacturer provides a driver that handles the synchronization of the computer clock. The
GPS170PCI card, as shown in Figure 3.11.1-2, synchronizes the system time of computers
with PCI/PCI-X bus interface.

A070484

Figure 3.11.1-2 Meinberg's GPS170PCI clock

28
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

The accuracy of the time depends on the components participating in the synchronization,
including the receiver, the SNTP client and the internal clock of the computer. Typically
an accuracy of +- 1 ms can be reached.

3.11.2. DCF77

DCF77 is a radio signal that can be used to synchronize the computer. The DCF77 radio
receiver, the Meinberg’s board PCI511, as shown in Figure 3.11.2-1, has been designed
for the reception of the DCF77 signal, to transfer the time information to a computer
with PCI (PCI-X) bus interface and the translation of the received codes into a serial
telegram.

A070483

Figure 3.11.2-1 Meinberg's PCI511

3.12. Redundancy

3.12.1. Server redundancy

The availability of a SYS 600 system can be further improved by redundant servers
configured in hot stand-by mode (HSB). The HSB concept defines redundancy between
applications, which means, there is always a pair of applications in a hot stand-by relation.
This relation means that one application is active and receiving and processing all the
data from the process. It is also managing the displays and providing data for the displays.
At the same time, all process data, configuration data and so on are shadowed over to
the stand-by application. The stand-by application will, at all times, be in exactly the
same state as the main application. If the computer, in which the main application runs,
breaks down, the stand-by application will take over the process communication and

29
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

continue to manage the process. In this way, the process can be operated and supervised
even if one server computer fails.

The HSB configuration can be applied both on system servers and communication
servers. When the HSB concept is applied on a communication server, the communication
server is equipped with a base system and a local process database. The process data is
transferred to the system server using the data mirroring functionality.

3.12.2. Communication redundancy

Redundant communication lines means that two or several connections between the
master and the slave form one logical connection. One of the connections is active and
if the active connection fails another connection is used instead.

Redundant communication lines are supported for IEC 60870-7-101 slave, RP-570 slave
and IEC 60870-7-104 master and slave.

3.13. Mirroring
The process data mirroring provides a powerful means for sharing process data in a SYS
600 network with minimal engineering effort. This can be used to build hierarchical
systems, for example, with one main control center, a number of regional control centers
and more local control centers or substations. It can also be used for load distribution in
large systems. The data mirroring can also be used to share data between a SYS 600
HMI and SYS 600 Gateway (COM 500i), for example, when communication protocols
are used that can have only one master. Mirroring can even be used to share process data
among totally different kinds of applications. For example, electrical SCADA and district
heating SCADA can share some indications, measurements and events.

The advantage of using data mirroring instead of standard communication like IEC
60870-5-104 is that, the data mirroring communication is much more efficient and the
required engineering work to build up the system is minimal. In addition, several special
functions, such as event buffering during communication breaks and handling of hot
stand-by configurations, are automatically taken care of.

The data mirroring takes place between a Host and an Image. The Host is the source for
the process data and the Image is a copy of the process data. The SYS 600 node that
receives the process data, for example, through IEC 61850 or LON is the Host. This
process data can be mirrored to another SYS 600 node which acts as an Image.

The data mirroring function is defined per SYS 600 Station object (STA). When a station
is configured for data mirroring, all process objects connected to that station are mirrored
according to the mirroring definitions of that station. Each station can only have one
source for the process data, either the process itself or a Host station in another SYS 600
node. But the process data of one station can be mirrored to 1-10 Image stations. A station

30
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

can also act both as Image and Host. In this way a hierarchical system in several levels
can be built up.

Although the mirroring typically takes place between different computers, it is also
possible to mirror data from one application to another in the same base system.

3.14. OPC connectivity

OPC is a de-facto interface standard when connecting various devices and systems within
the process automation industry. OPC is also becoming more and more used and accepted
also in other application areas and within the power industry. It defines the exchange of
data between a server and a client. The server provides data and the client uses the data.
The client can also write data (commands, parameters and so on) to the server.

SYS 600 provides OPC connectivity both in forms of clients and servers, that is, SYS
600 can receive data from a device or system that provides its data through an OPC
server, as shown in Figure 3.14-1. SYS 600 can also provide its data to another system
that acts as a client.

A070736

Figure 3.14-1 OPC connectivity

31
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

3.15. Capacity and performance scalability

The SYS 600 system is highly scalable with regards to capacity and performance. This
allows systems of significant differences in size to be built, starting from small monitoring
systems with tens of IO's to large systems with hundreds of thousands of IOs.

The capacity and performance of the system is mainly affected by the computer processing
capacity, which can be adjusted in two ways:

• by using computer(s) with various processing capacity

• by using various numbers of computers

3.15.1. Computer capacity

The computer type can be selected in order to match the capacity requirements of the
system. The most important parameters are listed below:

• CPU performance
• RAM capacity
• Disk capacity

The most important system characteristics, that should be considered when designing
the system are listed below:

• Process communication load

• Number of simultaneous workplaces
• Intensity of archiving, calculations and reporting
• Possible other system specific functions

3.15.2. Distributing processing capacity

In this context, one system is characterized by one common image of the process. This
means, in SYS 600 terms, one common process database and one common event archive,
which allows all alarms and events, to be managed in one alarm/event list. If this one
common process image is not required, the system can be built up of several independent
sub-systems, for example, with common workstations but with individual workplaces
for the different sub-systems. In the system, there is always one server that hosts the
complete process database. This server can of course be redundant (HSB) as described
in a separate chapter. The process database is, however, very efficient and can handle
tens of thousands of updates per second. Functions, that can be distributed, are process
communication (PC-NET, IEC 61850 OPC Server & Client), Archiving, Reporting,
Workplace processing and other post-processing activities. The functions are distributed
so that so that each computer is allocated to its own task and the process data is mirrored
between the computers by means of the Mirroring function in SYS 600.

32
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

A070470

Figure 3.15.2-1 Example with distributed system servers

Figure 3.15.2-1 is an example of a system where different functions have been distributed

to achieve a higher capacity. The process image of the system server can be mirrored up
to ten different servers. The number of communication front-ends connected to the system
server is mainly limited by practical factors and the system server capacity. All nodes
connected to the system by means of the mirroring functionality have SYS 600 installed.

A070471

Figure 3.15.2-2 Example with distributed IEC 61850 front-ends

The communication front-end can also be distributed in other ways, depending on the
communication protocols used. In an IEC 61850 system, the External OPC DA Client
and the IEC 61850 OPC server can run in its own computer. In addition to that, protocols
or protocol converters implemented with CPI (Communication Programming Interface),
can run in its own computer. For more information on building the IEC 61850 system,
see SYS 600 IEC 61850 System Design.

3.16. Product licensing

The functionality of the SYS 600 product is dependent on the product license. The license
describes about the functions that can be used, the size or capacity of a specific function,
as well as, the time during which the product can be used.

33
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

The license is delivered as a paf file (product authorization file) and is installed in the
product by means of a dedicated tool.

The license is locked to a specific hardware with the help of one or several hardware
keys. The license includes information about which hardware keys that are used. If one
of the specified hardware keys is present the license is enabled. If the hardware keys are
missing the license is disabled. The hardware key is a USB stick that is installed into a
USB port of the computer.

The hardware keys are identified by a unique ID number that is printed on the USB stick.
The corresponding number is also used in the license.

The License can define if the hardware key is installed in the local computer or in another
SYS 600 computer in the same SYS 600 network.

If the hardware lock becomes invalid during operation, SYS 600 will work without
restrictions for one week. During this time, the hardware lock should be fixed.

The following changes in the status of the hardware lock are reported:

1. Changes in the status of the hardware lock: valid <-> invalid

2. Missing hardware key
3. Found hardware key

34
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

4. Configuration
The SYS 600 system configuration is composed of objects and definitions for the base
systems and process communication units, as shown in Figure 4.1-1.

The main components for the configuration are the following:

• Each base system contains a set of base system objects that specify the base system
itself and its environment. During the operation, the base system objects are in the
primary memory of the base system computer. The base system objects are created
with SCIL commands when the MicroSCADA Pro base system is started. They can
be added and modified during the operation.
• Each process communication unit contains a set of system objects that specify the
unit itself and its environment. During the operation, the system objects are in the
memory of the PC (for example, process communication type PC-NET). Typically
these system objects has been configured by the SCIL programs. Otherwise the
default values given by the process communication units will be applied. The system
objects can be added and modified during the system operation.
• Process communication units of type IEC 61850 with External OPC DA Client are
configured using the Communication Engineering Tool for IEC 61850 OPC Server.

4.1. Configuring system server

As a rule, when a device is added to the MicroSCADA Pro system, several configuration
modules are affected. For example, when a process unit (station) is connected to a NET,
additions and modifications are required in:

• base system which uses it: base system objects.

• communication unit to which it is directly connected: system objects.

Concerning PC-NET and communication protocols, the configuration work is done with
the System Configuration Tool. It automatically gives default values which can be
changed, if needed.

The MicroSCADA Pro system configuration can be changed any time. However, in
some cases, like when a new station is added to the system, a shutdown and restart is
required for activating the changes.

35
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

A071351

Figure 4.1-1 The configuration software modules in MicroSCADA Pro

36
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

4.1.1. Hardware and operating system

A070491

Figure 4.1.1-1 Operating system architecture

MicroSCADA Pro supports Intel x86 compatible processors and Microsoft’s x32 (32-
bit) compatible operating systems: Windows XP, Windows Server 2003, Windows 7
and Windows 2008 Server. For information on requirements, see SYS 600 Installation
and Administration Manual.

MicroSCADA Pro can be installed as part of Windows domain, but it cannot be installed
to the domain server. A Windows domain is a logical grouping of computers that share
common security and user account information. This information is stored in a master
directory database (SAM) which resides on a Windows server designated as a domain
controller.

We recommend to use MicroSCADA in a stand-alone server to avoid complicated errors.

4.1.2. Base system (SYS)

The configuration of the MicroSCADA Pro base system is defined in the

SYS_BASCON.COM configuration file. The configuration file SYS_CONFIG.PAR is
a text file containing settings of memory parameters that cannot be set with SCIL (for
more information, see 4.1.2.2, Memory configuration). The file is read at system start-
up before the execution of SYS_BASCON.COM.

4.1.2.1. Base system objects

The file SYS_BASCON.COM is a text file containing SCIL statements for creating the
base system (B) objects. The system base software package contains a

37
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

SYS_BASCON.COM template file. The template file contains all the significant state-
ments for configuring both single and hot stand-by systems. During installation,
SYS_BASCON$COM is copied to SYS_BASCON.COM if the SYS_BASCON.COM
does not previously exist.

The contents of the SYS_BASCON$COM file is listed below. Some configuration

definitions have been excluded by commenting them. They can be taken into use by
removing the comment sign (;) in front of the SCIL lines that creates the base system
object.

To edit the current SYS_BASCON.COM in Notepad, open MicroSCADA Control

Panel > Admin > Config.

The contents of the current SYS_BASCON.COM can be indirectly edited with the System
Configuration Wizard. The wizard enables the elementary configuration and is specifically
intended for persons unfamiliar to SCIL programming. The wizard is started with the
MicroSCADA Control Panel, open MicroSCADA Control Panel >Admin > Wizard.
For more information, see 5.1, System Configuration Wizard.

The template file SYS_BASCON$COM consists of three different sections: a variable

definition section, a statements section, and a project-specific section. The actual config-
uration definitions are made in the variable definition section. The statements section
contains the SCIL language statements for creating all the base system objects. This
section is not intended to be modified by a project engineer. The last section in the end
of the file is reserved for project- and site-specific configuration code.

The contents of the template file SYS_BASCON$COM is presented in the following.

All variables are defined in the beginning of the file. The variable definitions section is
also divided to groups. The first group is called Quick configuration part, which includes
the definitions that can be modified either with the wizard or manually.
;File: Sys_bascon.com
;Description: Standard Base system configuration file
; for Single and Hot Stand-By systems
; Version 9.3 FP1
;----------------------------------------------------
;
;The quick configuration information below is written by the configuration wizard
or
;it can be modified manually.
;
;Quick configuration begin
;
#local Hot_Standby = FALSE ;Hot Stand-by enabled/disabled
#local Apl_Names = vector("MAIN") ;Application Name vector, main
applications
#local BS_Names = vector("SYS_1","SYS_2") ;Base System Node Names
#local BS_Nodes = vector(9,10) ;Base System Node Numbers
#local BS_Addresses = vector(209,210) ;Base System Station Addresses
#local This_Node_is = BS_Nodes(1) ;This system 1 or 2 (Always 1 for single
system)
;
#local COM500 = vector(TRUE) ;TRUE = COM500i application, FALSE =

38
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

not COM500i application

#local OPC_Server_Enabled = TRUE ;OPC Server enabled/disabled
#local OPC_AE_Server_Enabled = vector(TRUE) ;OPC A&E Server enabled/disabled
;
;Quick configuration end
;

The second group of variable definitions is called Basic configuration part and it includes
all the definitions for base system object configuration. The code includes examples to
help the project engineer in the configuration work.
;Basic configuration begin
;
;Application numbers. Empty vector = automatic numbering from 1 to
max_application_number
;Hot Stand-by Application numbers in the order:
;(MAIN1, MAIN2, ... , WATCH-DOG, ADJ MAIN1, ADJ MAIN2, ... , ADJ WATCH-DOG)
;An example of three main applications
; MAIN1
; . MAIN2
; . . MAIN3
; . . . WD
; . . . . ADJ_MAIN1
; . . . . . ADJ_MAIN2
; . . . . . . ADJ_MAIN3
; . . . . . . . ADJWD
; . . . . . . . .
;#local Apl_Numbers = vector(1, 2, 5, 6, 7, 8, 11, 12)

#local Apl_Numbers = vector()

;Image Stations for System Messages (max. 10 for each main application)
#local Apl_Image_Stations = vector()

;An example. Three applications with one image station each

;#local Apl_Image_Stations = vector(vector(list(APL = 15, UN = 91)),-
; vector(list(APL = 16, UN = 92)),-
; vector(list(APL = 17, UN = 93)))

#local LAN_Link = 1 ;LAN link number

#local Number_of_Printers = 0 ;Number of Printers

#local Pri_Numbers = vector(1,2)

#local Number_of_VS = 6 ;Number of VS monitors

#local Number_of_X = 0 ;Number of X monitors

;
;Other Base System Nodes
;
#local NOD_Numbers = vector(),- ;for example vector(11,12),-
NOD_Names = vector("NOD_11","NOD_12"),-
NOD_Addresses = vector(211,212)

;
;Gateway Nodes
;
#local GW_NOD_Numbers = vector(),- ;for example vector(20,22),-
GW_NOD_Addresses = vector()
;
;OPC DA and OPC A&E Nodes

39
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

#local OPC_DA_NOD_Numbers = vector()

#local OPC_DA_NOD_RN = vector()
#local OPC_DA_NOD_OP = vector()

;An OPC DA example, two OPC DA nodes

;#local OPC_DA_NOD_Numbers = vector(101, 102) ;Node numbers
;#local OPC_DA_NOD_RN = vector(0, 0) ;Routing node: 0 = current SYS node
;#local OPC_DA_NOD_OP = vector(list(CI = "{CE0322A9-65A9-4268-84D5-DD7A17E94C56}",-
; US = "username",-
; PW = "password",-
; SN = "DA Server 1",-
; SK = "",- ;Currently recognized: "AC
800"
;ABB AC 800 series
; GR = vector(-
; list(IG = "Group name",-
; UR = 0,-
; PR = 0.0))),-
; list(CI =
"{2E565242-B238-11D3-842D-0008C779D775}",-
; US = "username",-
; PW = "password",-
; SN = "DA Server 2",-
; SK = "",- ;Currently recognized: "AC
800"
;ABB AC 800 series
; GR = vector(-
; list(IG = "Group name",-
; UR = 0,-
; PR = 0.0))))

#local OPC_AE_NOD_Numbers = vector()

#local OPC_AE_NOD_RN = vector()
#local OPC_AE_NOD_OP = vector()

;An OPC A&E example, two OPC A&E nodes

;#local OPC_AE_NOD_Numbers = vector(111, 112) ;Node numbers
;#local OPC_AE_NOD_RN = vector(0,0) ;Routing node: 0 = current SYS node
;#local OPC_AE_NOD_OP = vector(list(CI = "{386CAD37-3798-42BA-A6BD-086A022CE803}",-
; US = "username",-
; PW = "password",-
; SN = "AE Server 1",-
; SK = "",- ;Currently recognized: "AC
800"
;ABB AC 800 series
; AA = 0 ),-
; list(CI = "{68AEC2B0-93CD-11D1-94E1-0020AFC84400}",-
; US = "username",-
; PW = "password",-
; SN = "AE Server 2",-
; SK = "",- ;Currently recognized: "AC
800"
;ABB AC 800 series
; AA = 0 ))

#local OPC_Nod_DI = 20 ;Diagnostic interval

;
;OPC Stations
;
#local OPC_DA_Station_Numbers = vector() ;Station numbers
#local OPC_DA_Station_Nodes = vector() ;The node numbers of the node object
that specifies

40
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

;the OPC server of the station

;An OPC DA station definition example

;#local OPC_DA_Station_Numbers = vector(1,2)
;#local OPC_DA_Station_Nodes = vector(101,102)

#local OPC_AE_Station_Numbers = vector() ;Station numbers

#local OPC_AE_Station_Nodes = vector() ;The node numbers of the node object
that specifies
;the OPC server of the station

;An OPC A&E station definition example

;#local OPC_AE_Station_Numbers = vector(11,12)
;#local OPC_AE_Station_Nodes = vector(111,112)

;
;External Applications for mirroring
;
#local Ext_Apl_Numbers = vector(),- ;for example vector(15,16),-
Ext_Apl_NA = vector("EXT_1","EXT_2"),-
Ext_Apl_ND = vector(11,12),-
Ext_Apl_SN = vector(12,11),- ;Shadowing partner application
Ext_Apl_TN = vector(1,1),-
Ext_Apl_EM = 5000,- ;Maximum length of mirroring queue
Ext_APl_EP = "KEEP" ;Event queue overflow policy, "DISCARD"
or "KEEP"

;
; Base System Object SYS attributes
;
#local Sys_Modify = list(-
-; Communication Attributes
ER = 0,- ;Enable Routing 0=disabled, 1=enabled
TI = 10,- ;Timeout Length
-; Time Handling Attributes
TM = "SYS",- ;Time Master, SYS or APL
TR = "LOCAL",- ;Time Reference, LOCAL or UTC
TF = 0,- ;Time Format
-; 0 = yy-mm-dd hh:mm:ss
-; 1 = dd-mm-yy hh:mm:ss
-; 2 = mm-dd-yy hh:mm:ss
-; Memory Handling Attributes
PC = 8192,- ;Picture Cache Size(kB)
RC = 8192,- ;Report Cache Size(kB)
-; MS-STOOL Settings
SV = (0,- ;System Variables
list(t_System_Configuration_File = "sys_/SysConf.ini",- ;PC-NET
Configuration

;information
b_Conf_Mech_In_Use = TRUE,- ;enables/disables start-up
configuration
b_SSS_Mech_In_Use = TRUE,- ;enables/disables system
self supervision
;routing
t_Version = "9.3")),-
-; Operating System Event Handles Attributes
OE = 0,- ;1=Enabled, 0=Disabled
OT = (Bit_Mask(0,1,2,3,4),- ;Application events (Bit 0=ERROR,
1=WARNING,
;2=INFORMATION, 3=AUDIT_SUCCESS,
4=AUDIT_FAILURE)
Bit_Mask(0,1,2,3,4),- ;System events (Bit 0=ERROR,
1=WARNING,

41
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

;2=INFORMATION, 3=AUDIT_SUCCESS,
4=AUDIT_FAILURE)
Bit_Mask(0,1,2,3,4))) ;Security events (Bit 0=ERROR,
1=WARNING,
;2=INFORMATION, 3=AUDIT_SUCCESS,
4=AUDIT_FAILURE)
;
; Node Object NOD attributes
;
#local Nod_Modify = list(-
DF = 1,- ;Diagnostic event from first FOUND
(0=System event not
;generated, 1=System event generated)
DI = 20,- ;Diagnostic interval
DT = 5) ;Diagnostic timeout
;
; Application Object APL attributes
;
#local Apl_Modify = list(-
NA = Apl_Names(1),- ;Application name
TT = "LOCAL",- ;Translation type
AS = "COLD",- ;Application state
PQ = 5,- ;Parallel queues
AA = 10,- ;Number of APL-APL servers (1..10)
SR = 1,- ;Shadowing maximum receive wait time in
seconds
HP = "DATABASE",- ;History Logging Policy ("DATABASE",
"EVENT_LOG", "NONE")
EE = 0,- ;System Events & Operating System Events
(1=Enabled,
;0=Disabled)
QM = (- ;Maximum queue lengths:
10000,- ; Time channel queue
10000,- ; Event channel queue
15000,- ; Parallel queues
10000),- ; Delayed exec queue
EM = 5000,- ;Maximum process event queue length
DI = vector(),-
DT = vector()),-
-; Apl-Apl Diagnostic
Apl_DI = 0,- ;Application diagnostic interval (0 =
Disabled)
Apl_DT = 5 ;Application diagnostic timeout
;
; Printer Object PRI attributes
;
#local Pri_Modify = list(-
-; Common attributes
TT = "LOCAL",- ;Translation Type
DC = "LINE",- ;Device Connection
DT = "TRANSPARENT",- ;Device Type
-; Printer connection attributes
ND = 0,- ;Node Number of NET unit (to be defined
if DT = "NET")
SD = "\\PrintServer\Printername",- ;System Device Name
-; Printout attributes
LP = 0,- ;Lines per Page
PN = 0,- ;Page Number
-; Printer queue attribute
QM = 1000,- ;Queue Length Maximum
-; Printer log attributes
LD = "",- ;Log Directory
LL = "DAY",- ;Log Length
LF = 1000,- ;Log Flush Timeout

42
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

OD = "PRINTER",- ;Output Destination

-;
OJ = 1,- ;Open on Job Basis
-;
CX = "") ;Comment Text

;
;Host stations are typically defined with the PC-NET system configuration tool.
;Image stations, gateway stations etc. can be defined here.
;
#local Stations = vector()
#local Sta_Nodes = vector()
#local Sta_ST = vector()
#local Sta_MR = vector()
#local Sta_H_Apl = vector()
#local Sta_H_UN = vector()
#local Sta_I_Apl = vector()
#local Sta_I_UN = vector()

;An example of STA object definitions for NCC level (MR = "IMAGE") stations in
the following
;
;#local Stations = ( 1005, 1012, 1031, 1042, 3051, 91 )
;#local Sta_ST = ( "PLC", "SPA", "IEC", "STA", "REX", "STA" )
;#local Sta_Nodes = ( 0, 0, 0, 0, 0, 0 )
;#local Sta_MR = ("IMAGE","IMAGE","IMAGE","IMAGE","IMAGE","IMAGE")
;#local Sta_H_Apl = ( 13, 13, 13, 13, 13, 13 )
;#local Sta_H_UN = ( 5, 12, 31, 42, 51, 0 )
;
;An example of STA object definitions for intermediate level (MR = "BOTH") stations
in the following
;
;#local Stations = ( 1005, 1012, 1031, 1042, 3051, 91 )
;#local Sta_ST = ( "PLC", "SPA", "IEC", "STA", "REX", "STA" )
;#local Sta_Nodes = ( 0, 0, 0, 0, 0, 0 )
;#local Sta_MR = ("BOTH", "BOTH", "BOTH", "BOTH", "BOTH", "BOTH" )
;#local Sta_H_Apl = ( 13, 13, 13, 13, 13, 13 )
;#local Sta_H_UN = ( 5, 12, 31, 42, 51, 0 )
;#local Sta_I_APL =
(vector(15),vector(15),vector(15),vector(15),vector(15),vector(15) )
;#local Sta_I_UN =
-;(vector(2005),vector(2012),vector(2031),vector(2042),vector(2051),vector(2091))

;
;Basic configuration end
;

The third group is the Variable declarations part, which includes local variable declara-
tions. A project engineer can add new variables to the end of this part for the site-specific
configuration code.
;
;Variable declarations
;
#local Sys,-
Sys_Permanent = list(),-
Sys_Supersede = list(),-
Sys_ND,-
Sys_OP,-
Sys_SA,-
Sys_SH,-
Adj_Sys_ND,-

43
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

Adj_Sys_SA

#local Nod,-
Nod_Permanent = list(),-
Nod_Supersede = list(),-
Nod_NN,-
Nod_Nb,-
Nod_SA,-
Nod_RN,-
Nod_OP

#local Sta,-
Sta_Nb,-
Sta_ND

#local Apl,-
Apl_AP,-
Apl_Count,-
Apl_Permanent = list(),-
Apl_Supersede = list(),-
Apl_Nb,-
Apl_IS,-
Apl_OE,-
Apl_SC,-
Apl_SF,-
Apl_SI,-
Apl_SY,-
Apl_SV = vector()

#local Pri,-
Pri_Nb,-
Pri_Permanent = list(),-
Pri_Supersede = list(),-
Printer_Mapping

#local First_Free_Mon,-
Mon,-
Monitor_Mapping

#local Global_Paths,-
Standard_Paths

#local i, j, Stat

The statements section of the SYS_BASCON.COM file contains the SCIL program to
create the base system objects and start applications and PC-NET. This section is not
intended to be modified by a project engineer.
;Initialize application numbers if not done yet
;

#if Hot_Standby #then Apl_Count = 2 * (length(Apl_Names) + 1)

#else Apl_Count = length(Apl_Names)

#if length(Apl_Numbers) == 0 #then #block

#loop_with i = 1 .. Apl_Count
Apl_Numbers(i) = i
#loop_end
#block_end

;Definitions to replace obsolete kernel default attribute values with up-to-date

values

44
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

Sys_Supersede = list(-
DN = 3,- ;Default NET Node Number
DS = "SPA",- ;Default STA type
PA = Apl_Numbers(1)) ;Primary application = the first
main application

Nod_Supersede = list()

Apl_Supersede = list()

Pri_Supersede = list()

;***********************************************
;***********************************************
; Do not edit contents below this line -
; except project specific part in the end
;***********************************************
;***********************************************
;
Sys_Modify = merge_attributes(Sys_Modify, Sys_Supersede)
Nod_Modify = merge_attributes(Nod_Modify, Nod_Supersede)
Apl_Modify = merge_attributes(Apl_Modify, Apl_Supersede)
Pri_Modify = merge_attributes(Pri_Modify, Pri_Supersede)
;

Apl_SC = 120 ;Shadowing maximum connect time in seconds

Apl_SF = 100 ;Shadowing flush time in milliseconds
Apl_SI = Apl_SF ;Shadowing diagnostic interval
Apl_SY = 60 ;Shadowing time synchronization interval in seconds

#if Hot_Standby #then Sys_SH = 1

#else Sys_SH = 0

#if OPC_Server_Enabled #then Sys_OP = 1

#else Sys_OP = 0

;***********************************************
;Statements for creating Base System Objects (B)
;***********************************************

#if not Hot_Standby #then This_Node_is = BS_Nodes(1) ;to be sure!

#case This_Node_is
#when BS_Nodes(1) #block
Sys_ND = BS_Nodes(1)
Sys_SA = BS_Addresses(1)
#if Hot_Standby #then #block
Adj_Sys_ND = BS_Nodes(2)
Adj_Sys_SA = BS_Addresses(2)
#block_end
#block_end
#when BS_Nodes(2) #block
Sys_ND = BS_Nodes(2)
Sys_SA = BS_Addresses(2)
Adj_Sys_ND = BS_Nodes(1)
Adj_Sys_SA = BS_Addresses(1)
#block_end
#case_end

;***********************************************
;Base System Object (SYS)

45
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

;***********************************************

Standard_Paths = do(read_text("/STool/Def/Path_Def.txt"))

Sys_Permanent = list(-
ND = Sys_ND,- ;Node number
SA = Sys_SA,- ;Station address
SH = Sys_SH,- ;Shadowing enabled
OP = Sys_OP,- ;OPC Server
FS = "NEVER",- ;File synchronization criteria
PH = Standard_Paths)

Sys = merge_attributes(Sys_Modify, Sys_Permanent)

#create SYS:B = Sys

;***********************************************
;LAN link (LIN)
;***********************************************

#create LIN'LAN_Link':B = list(LT = "LAN")

;***********************************************
;Base system nodes (NOD) for Hot Stand-by system
;***********************************************

#if Hot_Standby #then #block

Nod = list()
#loop_with i = 1 .. length(BS_Nodes)
Nod_Nb = BS_Nodes(i)
Nod_SA = BS_Addresses(i)
Nod_NN = BS_Names(i)
Nod_Permanent = list(SA = Nod_SA, NN = Nod_NN, LI = LAN_link)
Nod = merge_attributes(Nod_Modify, Nod_Permanent)
#create NOD'Nod_Nb':B = Nod
#loop_end
#block_end

;***********************************************
;Other base system nodes (NOD) e.g. for Mirroring
;***********************************************
Nod = list()
#loop_with i = 1 .. length(NOD_Numbers)
Nod_Nb = NOD_Numbers(i)
Nod_SA = NOD_Addresses(i)
Nod_NN = NOD_Names(i)
Nod_Permanent = list(SA = Nod_SA, NN = Nod_NN, LI = LAN_link)
Nod = merge_attributes(Nod_Modify, Nod_Permanent)
#create NOD'Nod_Nb':B = Nod
#loop_end

;***********************************************
;Gateway nodes (NOD)
;***********************************************
Nod = list()
#loop_with i = 1 .. length(GW_NOD_Numbers)
Nod_Nb = GW_NOD_Numbers(i)
Nod_SA = GW_NOD_Addresses(i)
Nod_Permanent = list(SA = Nod_SA, LI = LAN_link)
Nod = merge_attributes(Nod_Modify, Nod_Permanent)
#create NOD'Nod_Nb':B = Nod
#loop_end

;***********************************************

46
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

;Printers (PRI)
;***********************************************

Printer_Mapping(1 .. max_printer_number) = 0
#do read_text("sys_/pr_default.dat") ;Control Sequences for the transparent
printer
#loop_with i = 1 .. Number_of_Printers
Pri_Nb = Pri_Numbers(i)
Printer_Mapping(Pri_Nb) = Pri_Nb
Pri_Permanent = list(CS = %CS, HF = %HF)
Pri = merge_attributes(Pri_Modify, Pri_Permanent)
#create PRI'Pri_Nb':B = Pri
#loop_end

;***********************************************
;Classic Monitors (MON)
;***********************************************

First_Free_Mon = 1
Monitor_Mapping(1 .. max_monitor_number) = 0
#loop_with i = 0 .. (Number_of_VS - 1)
Mon = First_Free_Mon
First_Free_Mon = First_Free_Mon + 1
Monitor_Mapping(Mon) = -1
#create MON'Mon':B = list(TT = "LOCAL", DT = "VS")
#loop_end

#loop_with i = 0 .. (Number_of_X - 1)
Mon = First_Free_Mon
First_Free_Mon = First_Free_Mon + 1
Monitor_Mapping(Mon) = -1
#create MON'Mon':B = list(TT = "LOCAL", CP = "SHARED", DT = "X")
#loop_end

;***********************************************
;Applications (APL)
;***********************************************

Global_Paths = do(read_text("sys_/sys_bascon.scl"), "GLOBAL_PATHS")

;The usage of OI & OX -attributes

Apl_SV(15) = list(-
Process_Objects=list(-
OI=list(-
Title1=VECTOR("Substation"),-
Title2=VECTOR("Bay"),-
Title3=VECTOR("Device"),-
Title4=VECTOR(""),-
Title5=VECTOR(""),-
Length1=10,-
Length2=15,-
Length3=5,-
Length4=0,-
Length5=0,-
Field1=VECTOR("STA"),-
Field2=VECTOR("BAY"),-
Field3=VECTOR("DEV"),-
Field4=VECTOR(""),-
Field5=VECTOR("")),-
OX=list(-
Title1=VECTOR("Object text"),-
Length1=30)))

47
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

#if Hot_Standby #then #block

;*** LOCAL WATCHDOG ***

Apl_Nb = Apl_Numbers(length(Apl_Names) + 1)
Apl_Permanent = list(-
NA = "WD",- ;Application name
AS = "HOT",- ;Application state
PQ = 2,- ;Parallel queues
HP = "NONE",- ;History Logging Policy ("DATABASE",
"EVENT_LOG", "NONE")
EE = 1,- ;System Events & Operating System
Events (1=Enabled, 0=Disabled)
MO = Monitor_Mapping,- ;Monitor mapping
PR = Printer_Mapping,- ;Printer mapping
AP = spread(APL'Apl_Nb':BAP, append(Apl_Numbers,
Ext_Apl_Numbers), append(Apl_Numbers, Ext_Apl_Numbers))) ;Application mapping

Apl = merge_attributes(Apl_Modify, Apl_Permanent)

#loop_with i = 1 .. max_application_number
Apl_AP = Apl.AP(i)
#if Apl_AP > 0 #then #block
Apl.DT(i) = Apl_DT
Apl.DI(i) = Apl_DI
#block_end
#loop_end

#create APL'Apl_Nb':B = Apl

;*** ADJACENT WATHDOG ***

Apl_Nb = Apl_Numbers(2 * (length(Apl_Names) + 1))
#create APL'Apl_Nb':B = list(-
NA = "ADJ_WD",- ;Application name
TT = "EXTERNAL",- ;Translation type
ND = Adj_Sys_ND,- ;Node number
TN = Apl_Numbers(length(Apl_Names) + 1)) ;Translated object number

#loop_with j = 1 .. length(Apl_Names)

;*** LOCAL HSB APPLICATION ***

Apl_Nb = Apl_Numbers(j)
#if length(OPC_AE_Server_Enabled) < j #then Apl_OE = 0
#else_if OPC_AE_Server_Enabled(j) #then Apl_OE = 1
#else Apl_OE = 0
#if length(Apl_Image_Stations) < j #then Apl_IS = vector()
#else APL_IS = Apl_Image_Stations(j)
Apl_Permanent = list(-
NA = Apl_Names(j),- ;Application name
AS = "COLD",- ;Application state (started by
WD)
OE = Apl_OE,- ;OPC A&E Server
PH = Global_Paths,- ;Global paths
SV = Apl_SV,- ;System variables (reserved)
SC = Apl_SC,- ;Shadowing maximum connect time
in seconds
SF = Apl_SF,- ;Shadowing flush time in
milliseconds
SI = Apl_SI,- ;Shadowing diagnostic interval
SY = Apl_SY,- ;Shadowing time synch interval
in seconds
SN = Apl_Numbers(length(Apl_Names) + 1 + j),- ;Shadow
application
SW = Apl_Numbers(length(Apl_Names) + 1),- ;Shadow

48
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

watchdog
IS = Apl_IS,- ;Image Stations for System Messages

MO = Monitor_Mapping,- ;Monitor mapping

PR = Printer_Mapping,- ;Printer mapping
AP = spread(APL'Apl_Nb':BAP, append(Apl_Numbers,
Ext_Apl_Numbers), -
append(Apl_Numbers,
Ext_Apl_Numbers)))
;Application mapping

#if j <= length(COM500) #then #block

#if COM500(j) #then - ;COM500i Application

Apl_Permanent = merge_attributes(Apl_Permanent, -
list(PQ = 16,- ;Number of
parallel queues
QD = (1,1,0,0,0,0,1,1,1,1,1,1,1,1,1,1))) ;Parallel
queue

;dedication

#block_end

Apl = merge_attributes(Apl_Modify, Apl_Permanent)

#loop_with i = 1 .. max_application_number
Apl_AP = Apl.AP(i)
#if Apl_AP > 0 #then #block
Apl.DT(i) = Apl_DT
Apl.DI(i) = Apl_DI
#block_end
#loop_end

#create APL'Apl_Nb':B = Apl

;*** ADJACENT HSB APPLICATION ***

Apl_Nb = Apl_Numbers(length(Apl_Names) + 1 + j)
#create APL'Apl_Nb':B = list(-
NA = substr("ADJ_" + Apl_Names(j), 1, 10),- ;Application name
TT = "EXTERNAL",- ;Translation type
ND = Adj_Sys_ND,- ;Node number
TN = Apl_Numbers(j)) ;Translated object number

#loop_end

#block_end
#else #block ; *** Single System ***

#loop_with j = 1 .. length(Apl_Names)

Apl_Nb = Apl_Numbers(j)
#if length(OPC_AE_Server_Enabled) < j #then Apl_OE = 0
#else_if OPC_AE_Server_Enabled(j) #then Apl_OE = 1
#else Apl_OE = 0
#if length(Apl_Image_Stations) < j #then Apl_IS = vector()
#else APL_IS = Apl_Image_Stations(j)
Apl_Permanent = list(-
NA = Apl_Names(j),- ;Application name
AS = "HOT",- ;Application state
OE = Apl_OE,- ;OPC A&E Server
PH = Global_Paths,- ;Global paths
SV = Apl_SV,- ;System variables (reserved)
IS = Apl_IS,- ;Image Stations for System Messages

49
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

MO = Monitor_Mapping,- ;Monitor mapping

PR = Printer_Mapping,- ;Printer mapping
AP = spread(APL'Apl_Nb':BAP, append(Apl_Numbers,
Ext_Apl_Numbers),-
append(Apl_Numbers,
Ext_Apl_Numbers)))
;Application mapping

#if j <= length(COM500) #then #block

#if COM500(j) #then - ;COM500i Application

Apl_Permanent = merge_attributes(Apl_Permanent, -
list(PQ = 16,- ;Number
of parallel queues
QD = (1,1,0,0,0,0,1,1,1,1,1,1,1,1,1,1))) ;Parallel
queue

;dedication

#block_end

Apl = merge_attributes(Apl_Modify, Apl_Permanent)

#loop_with i = 1 .. max_application_number
Apl_AP = Apl.AP(i)
#if Apl_AP > 0 #then #block
Apl.DT(i) = Apl_DT
Apl.DI(i) = Apl_DI
#block_end
#loop_end

#create APL'Apl_Nb':B = Apl

#loop_end

#block_end

;External Applications e.g. for Mirroring

;
#loop_with i = 1 .. length(Ext_Apl_Numbers)

Apl_Nb = Ext_Apl_Numbers(i)
Apl_Permanent = list(-
TT = "EXTERNAL",-
NA = Ext_Apl_NA(i),- ;Application name
ND = Ext_Apl_ND(i),- ;Host node number
SN = Ext_Apl_SN(i),- ;Shadowing partner
TN = Ext_Apl_TN(i),- ;Host application number
EM = Ext_Apl_EM,- ;Max. length of mirroring queue

EP = Ext_Apl_EP) ;Event queue overflow policy

#create APL'Apl_Nb':B = Apl_Permanent

#loop_end

;***********************************************
;Station Types
;***********************************************

Stat = do(read_text("sys_/sys_bascon.scl"), "STATION_TYPES")

;***********************************************

50
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

;Node, Link for PC-NET & Stations

;***********************************************

Stat = do(read_text("Sys_Tool/Create_C.scl"), "BASE_SYSTEM")

;***********************************************
;OPC DA nodes
;***********************************************
Nod = list()
#loop_with i = 1 .. length(OPC_DA_NOD_Numbers)
Nod_Nb = OPC_DA_NOD_Numbers(i)
Nod_RN = OPC_DA_NOD_RN(i)
Nod_OP = OPC_DA_NOD_OP(i)
Nod = list(NT = "OPC_DA", RN = Nod_RN, OP = Nod_OP, DI = OPC_Nod_DI)
#create NOD'Nod_Nb':B = Nod
#loop_end

;***********************************************
;OPC AE nodes
;***********************************************
Nod = list()
#loop_with i = 1 .. length(OPC_AE_NOD_Numbers)
Nod_Nb = OPC_AE_NOD_Numbers(i)
Nod_RN = OPC_AE_NOD_RN(i)
Nod_OP = OPC_AE_NOD_OP(i)
Nod = list(NT = "OPC_AE", RN = Nod_RN, OP = Nod_OP, DI = OPC_Nod_DI)
#create NOD'Nod_Nb':B = Nod
#loop_end

;***********************************************
;OPC DA stations
;***********************************************
Sta = list()
#loop_with i = 1 .. length(OPC_DA_Station_Numbers)
Sta_Nb = OPC_DA_Station_Numbers(i)
Sta_ND = OPC_DA_Station_Nodes(i)
Sta = list(ST = "OPC", ND = Sta_ND, TT = "EXTERNAL")
#create STA'Sta_Nb':B = Sta
#loop_end

;***********************************************
;OPC AE stations
;***********************************************
Sta = list()
#loop_with i = 1 .. length(OPC_AE_Station_Numbers)
Sta_Nb = OPC_AE_Station_Numbers(i)
Sta_ND = OPC_AE_Station_Nodes(i)
Sta = list(ST = "OAE", ND = Sta_ND, TT = "EXTERNAL")
#create STA'Sta_Nb':B = Sta
#loop_end

;***********************************************
;Stations for Mirroring etc.
;***********************************************

Sta = list()

#loop_with i = 1 .. length(Stations)

Sta_Nb = Stations(i)

Sta = list(TT = "EXTERNAL",-

ST = Sta_ST(i),-
ND = Sta_Nodes(i),-

51
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

TN = Stations(i),-
MR = Sta_MR(i),-
HS = list(APL = 0, UN = 0),-
IS = vector(list(APL = 0, UN = 0)))

#if Sta_MR(i) == "HOST" or Sta_MR(i) == "BOTH" #then #block

#loop_with j = 1 .. length(Sta_I_Apl(i))
Sta.IS(j) = list(APL = Sta_I_Apl(i)(j), UN = Sta_I_UN(i)(j))
#loop_end
#block_end
#if Sta_MR(i) == "IMAGE" or Sta_MR(i) == "BOTH" #then #block
Sta.TN = 0
Sta.HS = list(APL = Sta_H_Apl(i), UN = Sta_H_UN(i))
#block_end

#create STA'Sta_Nb':B = Sta

#loop_end

The last section in the end of the file SYS_BASCON.COM is reserved for project
and site specific configuration code.

;***********************************************
;Project and site specific configuration after this line
;***********************************************

If there is a configuration error in the SYS_BASCON.COM

file, the system might not start. Check the messages from the
Notification Window or SYS_ERROR.LOG.

4.1.2.2. Memory configuration

The kernel of SYS 600 base system applies the policy of pre-allocating the virtual memory
to be used during the whole session. Pre-allocation of the virtual memory is a usability
issue: it ensures that the kernel, once successfully started, is able to request the memory
resources it needs, whatever happens in the system.

Memory allocation by demand may cause the computer to run in "Virtual memory low
state", which severely degrades the performance and, in the worst case, makes the system
totally unusable.

Memory pools

The global memory pool is accessed by all SYS 600 base system processes. It is used
for process and report databases, execution queues, inter-process communication and so
on. The pool is pre-allocated and fixed in size. If it is exhausted, a Hot Stand-By switch-
over is initiated. In a non-HSB system, the kernel tries to continue, but the application
may not function properly.

52
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

A private memory pool is owned and used by one thread only. Private memory pools
contain SCIL objects, such as variables, SCIL programs and Visual SCIL objects, and
other private data of the thread. Currently, the main threads of classic monitor processes
(PICN, PICV and PICA) as well as the main threads of reporting (REPR) and printer
spooler (PRIN) processes have a private memory pool. In addition, the client specific
threads of the OPC Data Access Server (OPCS) have their own private memory pool.
The private memory pools have a configured maximum size to grow to. If the maximum
size is exceeded, the running SCIL program is terminated.

The pools are configured in the configuration file SYS_CONFIG.PAR, which is read at
system startup before the execution of SYS_BASCON.COM. If the SYS_CONFIG.PAR
file does not exist, the default values are used. A template, SYS_CONFIG$PAR, is
copied to \sc\sys\active\sys_ during the installation of SYS 600. SYS_CONFIG.PAR
can be edited with any text editor.

Remember to remove the comment sign (;) in front of the

lines.

SYS_CONFIG.PAR may contain the following parameters:

MEMORY_POOL_SIZE

This parameter specifies the size of the global memory pool in megabytes. Recommended
values are 64, 128, 192, 256, 384, 512, 768 and 1024. The default value is 256 (MB).
The maximum possible value is slightly dependent on the operating system and the
installed hardware and software. In any system, it is possible to define a 1 GB (1024
MB) pool, or a little larger.

For example, the line MEMORY_POOL_SIZE = 512 sets the size of the global memory
pool to 512 MB.

MAX_PRIVATE_MEMORY_POOL_SIZE

This parameter specifies the maximum size of the private memory pool of any thread.
The default value is 128 (MB). Recommended values are 32, 64, 128 and 256.

MEMORY_POOL_HOLE

Setting this parameter causes the SYS 600 startup code not to use the specified virtual
memory area for the global memory pool. The parameter should be written into the
parameter file only if an external program fails to initialize and displays an error message
of the following format in the Notification Window (and SYS_ERROR.LOG):

Add the following line to SYS_CONFIG.PAR and restart MicroSCADA

MEMORY_POOL_HOLE = 30000000 - 301FFFFF

The line should be copied to SYS_CONFIG.PAR exactly as shown in the error message.
After a restart, the program should start without errors. The configuration file can contain

53
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

several MEMORY_POOL_HOLE lines, because there is a slight possibility that even

the second startup fails now suggesting another hole in the address space of the pool.

The content of the SYS_CONFIG$PAR is:

; File: Sys_config.par
; Description: Configuration of static base system parameters
; Commented lines (with leading ';') show default values
; Version 9.3 FP1
;---------------------------------------------------------------
;
;MEMORY_POOL_SIZE = 256 ;Global memory pool size (MB)
; ;Recommended values: 64, 128, 192, 256, 384,
512, 768, 1024
;MAX_PRIVATE_MEMORY_POOL_SIZE = 128 ;Max private memory pool size (MB) for SCIL
threads
; ;(processes picn.exe, picv.exe, repr.exe,
opcs.exe)
; ;Recommended values: 32, 64, 128, 256
;
;Obsolete parameters -- still supported but not to be used in new applications:
;
;MEMORY_POOL_ADDRESS = 30000000 ;Memory pool start address
;ANALOG_SWITCH_STATE_OPEN = 2 ;The semantics for MicroTOPOLOGY of AI
;ANALOG_SWITCH_STATE_CLOSED = 1 ;process objects used for indicating the
;ANALOG_SWITCH_STATE_MIDDLE = 0 ;state of a switching device

Tuning memory pool sizes

If a classic monitor process (PICN, PICV or PICA) requires more memory than the
memory pool size allows, the dialog SCIL Application Error/Memory Pool Exhausted
is displayed. The dialog displays a critical error with information about the pool, which
caused the error. The information is either "Private memory pool exhausted" or "Global
memory pool exhausted". Report (REPR) and printer spool (PRIN) processes report their
memory pool problems in the Notification Window and SYS_ERROR.LOG.

If the private pool is exhausted, increase the value of

MAX_PRIVATE_MEMORY_POOL_SIZE and restart SYS 600, or optimize the picture,
Visual SCIL dialog or command procedure to use less private pool memory. Large SCIL
data structures, such as long vectors, are most likely consumers of memory. If the global
pool is exhausted, increase the value of MEMORY_POOL_SIZE.

The current usage of pools may be checked by evaluating the SCIL function
MEMORY_POOL_USAGE, for example, in the Test Dialog. The function takes one
argument, either “GLOBAL" or "PRIVATE", which specifies the pool to be investigated.
For example, MEMORY_POOL_USAGE("GLOBAL") evaluates to a list value, where
attribute USED tells the number of bytes used in the global memory pool and attribute
FREE the number of available free bytes. When the databases have been loaded and the
system is in its normal running state, the values USED and FREE should be of the same
size class. If FREE is much smaller than USED (less than half of USED), increase the
MEMORY_POOL_SIZE parameter by 50 or 100 %.

54
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

Oversized pools do not give any performance benefit on the

system; they only increase the required size of the paging file.
Increase the memory pool sizes only if the system has reported
a memory pool shortage error or the
MEMORY_POOL_USAGE function shows that the pool is
nearly full.

The size of the physical memory (RAM) of the computer does not affect the pool sizes
in any way.

The memory pools are allocated from the paging file ('swap file') of the computer. With
currently available disks, there is no need to optimize the size of the paging file to the
smallest possible. It is recommended that paging file size is set to at least 4 gigabytes.

Picture and report cache

The base system maintains two run-time caches of recently used disk-resident objects.
The memory space required by the caches is allocated from the global memory pool.

The Picture Cache contains classic monitor pictures and representations. The size of the
cache is defined by the PC (Picture Cache Size) attribute of the SYS object (SYS:BPC).
The recommended size in the SYS_BASCON$COM template is 8 MB. This value is
likely to be adequate for any system.

The Report Cache contains history data of data objects and SCIL programs of command
procedure objects. The size of the cache is defined by the RC (Report Cache Size)
attribute of the SYS object (SYS:BRC). The recommended size in the
SYS_BASCON$COM template is 8 MB. If the application intensively uses large data
objects, some enhancement in performance may be achieved by using a larger value.

4.1.3. Applications (APL)

The application data is stored in the SYS 600 base system computer as a directory branch
under the application directory apl. For example, the application software of the local
application "sample" is stored in the directory \sc\apl\sample. Figure 4.1.3-1 presents
an example of the definition of two applications.

The application directory branch with its subdirectories should

exist before a local application can be defined in the SYS 600
base system configuration (for more information, see
4.1.3.3, Adding applications).

55
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

A051602

Figure 4.1.3-1 Example of the fundamental definition of a base system and the definition of two
local applications

4.1.3.1. Configuring APL objects

The attributes of APL object are described in the System Objects manual.

At least one local application should be created in

SYS_BASCON. COM, given a name (NA), set to LOCAL
(TT) and to HOT (AS) and mapped for at least one monitor
(MO).

If the primary application is not defined while creating the SYS object (the attribute PA),
then the application that is created first in SYS_BASCON.COM is the default application.
If no application number is given while opening a classic monitor, the default application
is chosen. Likewise, if no application number given when using the program interface,
the default application is addressed.

4.1.3.2. Mapping devices

Monitors, printers and stations can be mapped for an application, which means that the
application recognizes the devices under logical numbers. The station mapping, for

56
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

instance, specifies the station numbers under which the application recognizes the stations.
The station mapping has the following format:

APLn:BSTi = j

i The logical station numbers as known to the

application.
j The real STA object numbers of the stations.

The printers and stations have a default mapping, which means that each logical applic-
ation recognizes them under the real object numbers. Therefore, the printer and station
mapping is needed only if the application for some reason needs to know the devices
under logical numbers. If there are no obstacles, let the logical numbers be the same as
the object numbers (that is i = j), do not change the default values of printer and station
mapping.

4.1.3.3. Adding applications

To add a MicroSCADA application, follow the instructions given below:

1. Click Control Panel > Admin > Application to open Control MicroSCADA
Applications dialog (as shown in Figure 4.1.3.3-1).
2. Click Add button and type in the application name with capital letters (up to 10
characters).
3. Click OK.

A071352

Figure 4.1.3.3-1 Adding an application
4. Depending on the usage of the application, prepare it for LIB 500.
5. Define application characteristic in file SYS_BASCON.COM.
6. When MicroSCADA is started for the next time, application definitions are taken
in use.

57
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

4.1.3.4. Removing applications

To remove a MicroSCADA application, follow the steps given below:

1. Stop running MicroSCADA.

2. Click Control Panel > Admin > Application to open Control MicroSCADA
Applications dialog.
3. Select application from the list > Remove.
4. Confirm operation.
5. Remove application definitions from the SYS_BASCON.COM.

4.1.4. Configuring license protection

When a license with a remote hardware key is installed in a system, node diagnostics
must be set up to the system(s) that are to be searched for the installed hardware key.

Node diagnostics is enabled by setting the Diagnostic Interval (DI) attribute of the base
system node:
#SET NODn:BDI = 30 ;'n' is the node number of the SYS 600 system
;that has (or may have) the dongle installed.
;Diagnostic interval is 30 seconds.

To check the status of the current license, open License Tool and click Status button.

4.2. Configuring workplaces

A workplace is a computer with mouse, keyboard and one or more physical monitors
that have connection with MicroSCADA system. Connection to MicroSCADA system
is established when user opens a monitor. The monitor can be either Classic Monitor or
Monitor Pro. Workplace can be either on server computer or on remote computer. If the
workplace is on remote computer, connection to server computer is established over the
network by using remote client. Remote client means that programs of the workplace
run on server computer, whereas graphical output and mouse/keyboard input of the
processes happen on client computer. Promoted technologies between MicroSCADA
server computer and remote workplace computer are Windows Remote Desktop Protocol
(RDP) and Citrix Independent Computing Architecture (ICA). Two alternative software
can be used for remote clients, they are Windows Terminal Server and Citrix Metaframe.

Classic Monitor

Classic monitor is a program for showing operator graphics that is implemented by using
graphical resources provided by SCIL/Visual SCIL environment that is proprietary for
MicroSCADA technology.

58
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

Monitor Pro

Monitor Pro is an application that is implemented by using graphical resources provided

by Windows operating system. Monitor Pro extends functionality of Classic Monitor by
introducing new features for process display navigation like zooming, panning and
decluttering. In addition to that, features of Windows graphical user interface are suppor-
ted more widely in application frame, like menu and toolbar customization by using
drag/drop, Windows standard dialogs for open, save, fonts, printing support and so on.

Configuring the server for workplaces

To enable RDP connections to server, add Terminal Server role to the server. This can
be done in Control Panel > Administrative Tools > Manage Your Server. If Citrix
Metaframe is used for remoting, Citrix server software should be installed to the server
computer. For more information about installing Citrix server software, contact customer
support.

For information about Terminal Server Licensing, see Microsoft website, Windows 2003
server help or Windows 2008 Server help. For more information about Citrix Metaframe
Licensing, see Citrix website or software documentation.

Configuring client computer for workplace

Client software should be installed on client computer to connect to server by using RDP
protocol before connection can be established. Client for Windows Terminal Server is
normally installed by default with Windows operating system. Normally it can be found
from Start menu > Programs > Accessories > Communications > Remote Desktop
Connection. see Microsoft website if the client program is not installed.

Alternative client software is Citrix Metaframe. For more information about installing
Citrix client software, contact customer support.

Executing commands on client computer

Usually some server initiated commands should be executed on client computer, like
acknowledging audible alarms, automatically opening RDP session, and so on. These
can be arranged by using third party software PsExec. For more information about
PsExec, contact customer support.

4.2.1. Windows terminal server

Terminal Services is a component of Microsoft Windows operating systems. It allows

a user to access applications on a remote computer over a network connection. For more
information, refer to Figure 4.2.1-1. Terminal Services is Microsoft's take on server

59
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

centric computing. Based on the Remote Desktop Protocol (RDP), Terminal Services
was first introduced in Windows NT 4.0 Terminal Server Edition. Next server products,
Windows Server 2003 and Windows 2008 Server have introduced several improvements
and new features. Terminal Services in Windows Server operating systems provides a
new option for MicroSCADA monitor deployment. This is required to open new
MicroSCADA Pro monitors from LAN connected workstations.

A070554

Figure 4.2.1-1 Windows terminal server

Operating System Licensing

Windows Server License

The Windows Server 2003 and Windows Server 2008 licensing model requires a server
license for each copy of the server software installed. Terminal Services function is
included in the Windows Server license.

Windows Server Client Access License

In addition to a server license, a Windows Server Client Access License (CAL) is also
required. If you want to conduct a Windows session, an incremental Terminal Server
Client Access License (TS CAL) is required as well. A Windows session is defined as
a session during which the server software hosts a graphical user interface on a device.
For Windows sessions, a TS CAL is required for each user or device.

Terminal Server Client Access Licenses

60
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

Two types of Terminal Server Client Access Licenses are available: TS Device CAL
and TS User CAL. A TS Device CAL permits one device (used by any user) to conduct
Windows Sessions on any of your servers. A TS User CAL permits one user (using any
device) to conduct Windows Sessions on any of your servers. A single license server
can support multiple terminal servers. There can be one or more license servers in a
domain, or throughout a site.

The Terminal Server Licensing Model

Terminal Server Licensing operates between several components, as shown in Fig-

ure 4.2.1-2:

A070474

Figure 4.2.1-2 Terminal server licensing model

For more information, refer to the Microsoft Windows Server 2003 Terminal Server
Licensing manual and Microsoft Windows Server 2008 Terminal Server Licensing
manual available in Microsoft’s website.

Operating mode: Application Server or Remote Administration

Terminal Services may be enabled in one of the two modes: Application Server or Remote
Administration. Application server mode allows multiple remote clients to access Win-
dows-based applications that run on the server. This mode should be used if many con-
current MicroSCADA Pro sessions are opened.

61
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

Remote administration mode is designed to provide operators and administrators remote

access. This feature allows you to connect to and manage a server remotely for up to
two connections. Since this is designed as a single-user remote access solution, no Ter-
minal Server Client Access License (CAL) is required to use Remote Administration.

Windows XP Remote Desktop allows the same function as Windows Server 2003 Ter-
minal Services. But there is always only one active remote desktop session at a time. If
someone logs into the computer from a remote location, the local user is disconnected.

Terminal Services works with client computers and terminals by using the Remote
Desktop Protocol (RDP). Terminal Services Client software for Windows-based com-
puters (RDP clients) is included in Windows Server operating systems. Non-Windows-
based clients require a third party add-on.

4.2.2. Citrix MetaFrame Application Server

Windows 2003 Terminal Services supports the native Microsoft Remote Desktop Protocol
(RDP) as well as the Citrix Independent Computing Architecture (ICA) protocol (via
the Citrix add-on).

Citrix MetaFrame/Presentation Server is a remote access/application publishing product

built on the Independent Computing Architecture (ICA), Citrix Systems' thin client
protocol.

This package consists of a handful of products that run on Windows Servers and go
beyond what Windows Terminal Services can do. Support of larger displays than on
Windows Server 2003 Terminal Services and seamless window mode (no frame on
application window) for instance are features, which can be achieved by using Citrix
features and may be useful in the MicroSCADA Pro workplace.

For information on features available for each protocol, see SYS 600 Installation manual.

4.2.2.1. Verifying client connections

A computer that can be accessed by a user working at a remote location is known as

host. Remote computer is known as the client. The remote desktop connection client
software should be installed in it. Use ping utility to check that TCP/IP connection
between your server and workstation is functional. Next, check the Terminal Services
connection by opening desktop for a user on the server. To do this, select Start > Pro-
grams (or All Programs) > Accessories > Communications > Remote Desktop
Connection, as shown in Figure 4.2.2.1-1.

62
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

A070553

Figure 4.2.2.1-1 Opening Remote Desktop Connection

Fill in the computer name or IP address of the host and click Connect. Log on to Windows
dialog box by typing your user name and password.

The Citrix client should be installed on your workstation computer to open ICA connec-
tions. It can be installed from Citrix MetaFrame installation CD or can be downloaded
for free from the Citrix website.

A070710

Figure 4.2.2.1-2 Opening Program Neighborhood

1. Open Program Neighbourhood, as shown in Figure 4.2.2.1-2.

2. Create connection client.
3. Type name for the connection, add server address, set options for connection and
give logon information.
If no application is given, then a desktop is connected in the ICA window. You
should have created user information on the server you want to log in.

If you are not allowed to open client connection, check

whether terminal services and licensing services are installed
on server. Also check the other server side connection settings,
as shown in Figure 4.2.2.1-3.

1. Open Terminal Services Configuration.

2. In the console tree, click Connections.
3. In the details pane, right-click the connection you want to modify, and then click
Properties.

63
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

A070711

Figure 4.2.2.1-3 Modifying connection settings

4.2.3. Defining MON objects

Base system configuration

Each classic monitor should be defined as a MON object in the connected base system.
Pro Monitors do not need MON objects. The MON objects should be mapped for the
applications, which use them. The monitor objects are defined equally, whether they are
opened on the base system monitor or on a workplace. Figure 4.2.3-1 shows an example
of a workplace with three classic monitors opened to three applications in two separate
base systems.

Make the following object definitions in each base system:

1. Create MONn:B objects, one for each classic application monitor that is opened on
the base system monitor or on connected workplaces. Assign the MON objects the
following attributes:
DT = “VS”
TT = "LOCAL"
You can create up to 100 MON objects per base system.
2. Define monitor numbers for each application by setting the APLn:BMO attribute
to -1 by using freely chosen monitor numbers as indexes.
Example
Application 1 is created with the following definition:
@MON_MAP(1..5) = -1
#CREATE APL1:B = LIST (-
....
MO=%MON_MAP
....
)

64
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

Now the value of indexes 1 ... 5 of attribute MO is -1 (APL1:BMO(1..5) = (-1,-1,-

1,-1,-1)), which means that monitor numbers 1 ... 5 can be opened to view application
1.

65
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

A051606

Figure 4.2.3-1 Example of a workplace that is connected to two base systems and four applications

66
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

4.2.4. Monitor Pro configuration

For information on command line support, see to SYS 600 Application Design.

Process Display Specific Configuration Files

Common Process Display Specific Menu Files

Common process display specific menu files are common for all process displays. Those
are seen in process display specific menu before the separator (if some user has logged
in Monitor Pro). Process display specific menu files are after the separator. For example:

Example

FRAMEWINDOW.EXE C:\samplepic.v
FRAMEWINDOW.EXE C:\samplepic.v -ll:100,400 -ur:300,500
FRAMEWINDOW.EXE C:\samplepic.v -display:0,0,400,400
FRAMEWINDOW.EXE C:\samplepic.v -light
FRAMEWINDOW.EXE alarmlist_temp1
FRAMEWINDOW.EXE -loginscript C:\samplefile.bat
FRAMEWINDOW.EXE C:\samplepic.v -loginscript C:\samplefile.bat
FRAMEWINDOW.EXE eventlist -loginscript C:\samplefile.bat
FRAMEWINDOW.EXE -login 510_403_1
FRAMEWINDOW.EXE -login demo "" 510_403_1
FRAMEWINDOW.EXE -login demo "" 510_403_1 C:\samplepic.v
FRAMEWINDOW.EXE -login demo "" 510_403_1 trends_graphical
my_trend_preconf
FRAMEWINDOW.EXE -login demo "" 510_403_1 alarmlist_temp1
my_alarm_preconf
FRAMEWINDOW.EXE -login demo "" 510_403_1 eventlist
my_event_preconf
FRAMEWINDOW.EXE -loginonce C:\samplepic.v
FRAMEWINDOW.EXE -loginonce alarmlist_temp1
FRAMEWINDOW.EXE -loginonce -loginscript C:\samplefile.bat
FRAMEWINDOW.EXE -loginonce eventlist -loginscript C:\samplefile.bat

Application Specific

Application specific common process display specific menu files are in folder [Appl
path]\PAR\APL\PROCESS\MENU.

User Specific

67
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

User specific common process display specific menu files are in folder [User
path]\PROCESS\MENU. If the folder exists, the contents of application common process
display specific menu folder is not investigated at all. This makes it possible, for example,
to skip the application common process display specific menu files if needed by just
defining an empty user specific one.

Visibility Shortcut Files

If visibility files have been defined, the following operations are blocked:

• File open-menu item will not allow user to open any process graphics pictures.
• Process graphics picture drag and drop to application window is not allowed.
• Custom commands concerning opening process graphics displays is blocked.

Application Specific

The shortcut files in [Appl path]\PAR\APL\PROCESS\TOOLBAR_SHORTCUTS are

shown to all users in application process displays toolbar in Monitor Pro. If this folder
is not empty (excluding user specific folders), the files in [Appl path]\PICT\ are left
investigated. Other process displays than the ones in application process displays toolbar
are not allowed to open.

For backwards compatibility, the existing files in old folder are moved programmatically
to new folder when Monitor Pro is started.

User Specific

The shortcut files in [User path]\PROCESS\TOOLBAR_SHORTCUTS\ are shown only

to appropriate user, in application process displays toolbar in Monitor Pro. If this folder
is not empty, the files in [Appl path]\PICT\ folder and application specific shortcut files
are left investigated. Other process displays than the ones in application process displays
toolbar are not allowed to open.

For backwards compatibility the existing files in old folder are moved programmatically
to new folder when Monitor Pro is started.

Process display menu

A process display menu displays both the common parts for the process pictures and the
specific parts for the currently active process picture.

The menu structure is similar to the Windows Start menu. The menu commands are
organized as folders and files in the file system. Therefore, no special tool is needed to
configure the menu. The configuration is done by organizing the files, such as programs,
documents or shortcuts and the directories in a file system. For example, a menu command
can be:

• a file
• a folder containing submenu commands

68
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

• a link
• a shortcut to a file
• a shortcut to a directory
• an Internet hyperlink

Defining shortcuts to process displays

The user access rights can be restricted by showing the required process displays as
shortcuts. The user can only open the process displays shown in a toolbar, if the shortcut
files have been defined.

The following operations are unavailable for the user:

• Opening process displays by using the menu operation Main > Open File.
• Dragging process displays to an application window.
• Custom commands related to opening the process displays are blocked.

Shortcut files should be there at the operating system level.

Copying the picture is not the correct way to create the short-
cuts.

Application specific process display shortcuts are shown to all users. The shortcut files
are located in Appl path]\PAR\APL\PROCESS\TOOLBAR_SHORTCUTS. The user
is not allowed to open process displays that are not defined on toolbar of the application
specific process displays.

User specific process display shortcuts are shown individually to each user. The user
specific shortcut files are located in [User path]\PROCESS\TOOLBAR_SHORTCUTS.
The user is not allowed to open process displays that are not defined on the toolbar of
the user specific process displays.

If the user specific shortcut files exists, the application specific

files are ignored.

Process Display Context Menus

MENUS directory

MENUS directory consists of directories such as all, objecttypes and instances.

• Menu commands, which are to be shown on each shortcut menu, should be stored
under the directory all.
• The directory objecttypes consists of all object types that a station overview can
have. Menu commands that each object type can have are also located here.

69
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

• It is also possible that an instance of a breaker might have some menu commands
that are instance specific, such as a figure of a breaker, online video stream, main-
tenance log or a web link to the manufacturers home page. In that case, the menu
commands are located in \<unique object id>.
• The menu for all objects are located in <apl>\MENUS\all.

SYS 600 supports two-letter language codes. When generating

the menu structure, use the /culture <language> option. When
the option is selected, the menu commands are displayed under
the culture specific folder.

Table 4.2.4-1 Menu command descriptions

Name Description Path

<apl> Path of the application For example,

C:\sc\apl\510_403_1
<object type> For more information about <apl>\MENUS\objecttypes\
object types, see Section <object type>(common menu
13.5.7. Object types in SYS for an object type)
600 Application Design
<display name> Name of the display file
(without extension .v)

Menu structures are not shadowed. If a HSB system is used,

the menus have to be manually copied between Hot stand-by
computers after the modifications have been done. Otherwise,
the directories are deleted during the switch over.

Troubleshooting

Table 4.2.4-1 Possible problems with context-sensitive shortcut menus

Description of the problem Possible cause Solution

Only a description of a shortcut There are no commands in the Check that the application has
menu is displayed. A message menu directory, that is, menu a menu structure. For more
'No items' or the icon indicates is empty. information, see SYS 600
that the shortcut menu is empty Application Design. Further-
more, check whether a culture
has been defined similar to the
user for the menu structure.
The folder is displayed as a
menu command and can be
browsed. The folder does not
contain submenu commands

70
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

Description of the problem Possible cause Solution

The command Open With dia- The file type of the menu com- Use the command Open With
log is displayed when running mand is unknown. The file has dialog to select the program in
a menu command not been associated with any which you want to open the file
program
A menu command is disabled User is not authorized to run Check the authorization level
the menu command or a link or the link target
target does not exist
The custom object type does A menu structure was not gen- Add a menu structure manually
not have menu commands erated for the custom object for the custom object type and
type or the type does not have ensure that the object has an
an SAObjectType attribute SAObjectType attribute
An instance specific menu No view was defined when the Use Display Builder to set the
structure is not created for a menu structure was generated Object Name field for the sym-
symbol or the symbol’s Object Name bol. Run the menu generator
field is empty and use a viewpath argument
to generate menus for
instances

4.2.4.1. OpenRemoteDesktop

The OpenRemoteDesktop program can be used for opening a connection from a work-
station to the active server in the MicroSCADA HSB system. The program that runs on
client computer inspects both servers, detects active server of HSB pair and establishes
a terminal server session to it.

The program transfers audible alarms from the server computer to the workstation
computer.

The program makes the following checks on the servers of the HSB pair when initializing
the connection:
• A ping request is made to detect if the server is available in the network. The check
is done for both servers.
• If the server responds to ping, the program detects if MicroSCADA is running on
the server using the same connection method as the MicroSCADA Notification
window. The check is done for both servers.
• If MicroSCADA is running on the servers, the program detects which one of the
servers contains the application that is in the HOT state.
• If the applications in both HSB servers are HOT, the connection is established to
the server that has an older timestamp (RT attribute) in the command procedure
APL_INIT_H. This shows that the server's application status became HOT earlier.
• After finding an appropriate HSB server that has the main application in the HOT
state, the program opens the Remote Desktop connection to that server.
• After opening the Remote Desktop session, the program stays active as a tray
application, and subscribes OPC items for the application state and an audible alarm
for monitoring.

71
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

• If the application goes to another state than HOT, the program automatically restarts
a procedure to find out the active server and to establish the connection.
• If an audible alarm occurs on the server, the program flashes the audible alarm icon
in the application tray and plays the alarm that is configured in the configuration
file.

Installing

Installing the OpenRemoteDesktop program to the workplace computer requires the

following steps:
1. You can find the OpenRemoteDesktop.exe file and other needed files in the directory
\sc\prog\utils\OpenRemoteDesktop on the server computer. Copy the contents of
this directory to a directory on the client computer.
2. Install OPC core components to the client computer by running the setup file OPC
CORE COMPONENTS 2.00 REDISTRIBUTABLE 2.00.MSI.
• You can find the OPC CORE COMPONENTS 2.00 REDISTRIBUTABLE
2.00.MSI file in the OPC_Core_Components subdirectory in the directory
\sc\prog\utils\OpenRemoteDesktop.

The client computer must have the Remote Desktop

client installed in it, and there must be the predefined
RDP session definition files on the client computer
for both server computers.

3. The Remote Desktop client program can be started with the following command:
Start menu > Programs > Accessories > Communications > Remote Desktop
Connection.
4. Configure the desktop connections and save the configurations in two different files,
one for each server computer. Use the file extension is RDP. Register MCI32.OCX
and MSCOMCTL.OCX if your client computer is using Windows 2003 server as
the operating system.

Configuring RDP files

To configure RDP files:

1. Start the remote desktop client program (RDP client configuration) by selecting
Start menu -> Programs -> Accessories -> Communications -> Remote Desktop
Connection (in Windows XP), or running the command mstsc from the command
line.
2. In the RDP configuration, define <drive>:\sc\prog\sa_lib\Framewindow.exe as the
startup program.
3. Define the working directory to <drive>:\sc\prog\sa_lib.
4. Define the parameters that close Monitor Pro without message boxes when applica-
tion switches to COLD state. To define the parameters, use the following command

72
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

line arguments: <drive>:\sc\prog\sa_lib\Framewindow.exe -sdown:closemonitorpro

-silentexit

INI file configuration

The program uses the configuration file OpenRemoteDesktop.ini that must be located
in same directory as the program file. The INI file should contain following required
and optional parameters in the option group OpenRemoteDesktop:

SERVER1 IP number or node name of primary server.

SERVER2 IP number or node name of secondary server.

The following parameters are optional:

RDP1 Remote Desktop Protocol (RDP) file defining

session to primary server.
RDP2 Remote Desktop Protocol (RDP) file defining
session to secondary server.
RDP1_1...RDP1_9 Additional Remote Desktop Protocol (RDP) files
defining session to primary server
RDP2_1...RDP2_9 Additional Remote Desktop Protocol (RDP) files
defining session to secondary server
SERVER1_APP Application number where to connect on primary
server. Default value is 1.
SERVER2_APP Application number where to connect on second-
ary server. Default value is 1.
PING_TIMEOUT The timeout (in milliseconds) how long the ping
command waits for the server to respond.
Default value is 500 milliseconds. This para-
meter also defines the timeout for getting
MicroSCADA running status.
BALLOON_TIMEOUT The timeout (in milliseconds) how long the bal-
loon notification stays on the screen. Note that
the minimum and maximum timeout defined by
the operating system are 10000 and 30000
milliseconds (respectively), so values that are
too large are set to the maximum value and
values that are too small default to the minimum
value.
CONNECTION_CHECK_INTERVAL The time (in milliseconds) how often the connec-
tion to the server is checked. Default value is
10000 milliseconds.
AUDIBLE_ALARM_OPC_ITEM The OPC item name for audible alarm process
object. The OPC item should be given without
attribute definition, i.e. the item name must be
\\APL\1\P\ACK_SOUND\1 rather than
\\APL\1\P\ACK_SOUND\1:OV.

73
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

AUDIBLE_ALARM_FILE_1 WAV audio file name for alarm sound 1.

AUDIBLE_ALARM_FILE_2 WAV audio file name for alarm sound 2.
AUDIBLE_ALARM_FILE_3 WAV audio file name for alarm sound 3.
AUDIBLE_ALARM_FILE_4 WAV audio file name for alarm sound 4.
AUDIBLE_ALARM_FILE_5 WAV audio file name for alarm sound 5.
AUDIBLE_ALARM_FILE_6 WAV audio file name for alarm sound 6.
AUDIBLE_ALARM_FILE_7 WAV audio file name for alarm sound 7.

The RDP session opening is not obligatory, OpenRe-

moteDesktop.exe can also be used for transferring audible
alarms only. In this case the RDP parameters can be left empty
in the INI-file.

Example contents of the configuration file:

[OpenRemoteDesktop]
SERVER1 = 192.168.8.10
SERVER2 = 192.168.8.11
RDP1 = SYS_1.rdp
RDP1_1 = SYS_1_1.rdp
RDP1_2 = SYS_1_2.rdp
RDP1_3 = SYS_1_3.rdp
RDP2 = SYS_2.rdp
RDP2_1 = SYS_2_1.rdp
RDP2_2 = SYS_2_2.rdp
RDP2_3 = SYS_2_3.rdp
AUDIBLE_ALARM_FILE_1 = C:\WINDOWS\Media\ding.wav
AUDIBLE_ALARM_FILE_2 = C:\WINDOWS\Media\start.wav
AUDIBLE_ALARM_FILE_3 = C:\WINDOWS\Media\recycle.wav
AUDIBLE_ALARM_FILE_4 = C:\WINDOWS\Media\ringout.wav
AUDIBLE_ALARM_FILE_5 = C:\WINDOWS\Media\chord.wav
AUDIBLE_ALARM_FILE_6 = C:\WINDOWS\Media\tada.wav
AUDIBLE_ALARM_FILE_7 = C:\WINDOWS\Media\notify.wav
SERVER1_APP = 1
SERVER2_APP = 1
PING_TIMEOUT = 500
BALLOON_TIMEOUT = 10000
CONNECTION_CHECK_INTERVAL = 10000
AUDIBLE_ALARM_OPC_ITEM = \\APL\1\P\ACK_SOUND\1

Audio alarm handling

The program monitors the value of the audio alarm process object on the server computer.
When the value of the process object changes to non-zero, audio alarm starts to play on
the client computer. When the audio alarm sound is on, the icon of the program in the
task bar changes to red animated loudspeaker. Logical name and index of the process
object can be configured in the INI file by defining the OPC item ID. The value of the
process object defines what audio sound will be played. For example, when the process
object value is 1, the audio file defined by the parameter AUDIBLE_ALARM_FILE_1

74
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

is played, when the value is 2, the audio file defined by the parameter AUD-
IBLE_ALARM_FILE_2 is played and so on. The audio alarm sound stops when the
process object value changes back to 0. The audio alarm continues to play until the process
object value is set to 0. The value can be set to 0, for example, in the command procedure
that is executed by clicking a toolbar button.

Indications

Following icons indicate status of the application in tray area of task bar:

Icon Description

The connection has been successfully established to the active server.

The connection to the active server has been lost.

Indicators for an audible alarm. The connection has been successfully established
to the active server, and the audible alarm is on.

When the application state changes, for example when the connection is established to
the server, the status changes are indicated to the user by showing a balloon in the tray
area:

A071337.png

Figure 4.2.4.1-1 Server is disconnected from the network

A071338.png

Figure 4.2.4.1-2 Finding servers again

75
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

A071339.png

Figure 4.2.4.1-3 Server is found, but MicroSCADA is not running

Message "Server found, but MicroSCADA is not running" can also mean that the work-
station user does not have the authority to access named pipes on the server computer.
To test the access rights, run notify.exe on the client computer and give the server name
as an command line argument. Example:
C:\sc\prog\exec\notify.exe 10.58.125.47

If the user does not have access rights for the named pipes, the following dialog is dis-
played:

A071340.png

Figure 4.2.4.1-4 Access Denied dialog

To solve the problem, log in to the workstation computer as a user that has sufficient
access rights to the server computer.

Program status

Check the status of the program by right-clicking the icon in the taskbar:

A071341.png

Figure 4.2.4.1-5 Program status

76
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

A071342.png

Figure 4.2.4.1-6 OpenRemoteDesktop status

Closing OpenRemoteDesktop

Select Exit from the context menu of the tray icon.

When you close the program, monitors are not opened to the
server.

Closing Terminal Server session

If you close the terminal server session, you can re-open it by double-clicking the icon
on the taskbar. If you try to restart the program when another instance of the program is
already running, an error message is displayed.

Error situations

The following error messages are displayed in case a HOT application is not found on
the servers of the HSB pair. If the server is not found in the network, that is, it does not
respond to the ping request, the program displays the error message "Server disconnected
from network". If MicroSCADA is not running, the program displays the error message
"Failed when making OpcServer Connect (Error: ActiveX component can't create object)".

This error message means that:

• MicroSCADA is not running on the computer, or
• DCOM settings of MicroSCADA OPC DA Server are not correct.

77
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

For instructions on how to set up DCOM and solve problems, see Setting up DCOM on
HSB server computers and How to solve DCOM problems. See Figure 4.2.4.1-7.

An error message for a running MicroSCADA OPC server (Server 1) without a valid
license is shown in Figure 4.2.4.1-8.

A071343.png

Figure 4.2.4.1-7 Error: ActiveX component cannot create object

A071344.png

Figure 4.2.4.1-8 Error: No valid license

If the MicroSCADA application is not in the HOT state, the program displays the error
message "Application <application number> state is not "HOT"". See Figure 4.2.4.1-9
(Server 1). In this case the OPC connection has been successfully established to the
server, and the application with given number exists in the system, and it is possible to
read application attributes via the OPC server.

A071345.png

Figure 4.2.4.1-9 Error: Application 1 state is not HOT

If the MicroSCADA application does not exist in the system, the program displays error
message "Application <application number> does not exist in system". See Figure 4.2.4.1-
10 (Server 1). In this case the OPC connection has been successfully established to the
server, but an application with the given number did not exist.

78
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

A071346.png

Figure 4.2.4.1-10 Error: Application 2 does not exist

If there is a DCOM authorization problem, usually the error message "Method '~' of
object '~' failed" is produced. See Figure 4.2.4.1-11. In this case, make a shortcut that
launches OpenRemoteDesktop.exe as a user that has DCOM access and launch permis-
sions to MicroSCADA OPC server on the server computer.

Define the same username and password for both the server
and client computer, or launch OpenRemoteDesktop.exe as
a domain user with an appropriate DCOM authority to the
server.

A071347.png

Figure 4.2.4.1-11 Error: Method '~' of object '~' failed

Setting up DCOM on workstation computers

To set up DCOM on workstation computers:

1. Go to Start -> Run and type DCOMCnfg and click on OK.
2. Click Component Services under the Console Root to expand it.
3. Click Computers under Component Services to expand it.
4. Right-click My Computer in the pane on the right and select Properties.
5. Go to the COM Security tab and edit the four permission configurations:
a. Edit the Limits for Access and Launch by selecting Permissions and then Edit
Limits....
b. Select the Remote Access checkbox for the user labeled ANONYMOUS LOGON
in the dialog.
c. Edit the Launch and Activation Permissions by selecting Edit Limits...
d. Select the Remote checkboxes for the user labeled Everyone in the dialog.

79
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

Since Everyone includes all authenticated users, it is

often desirable to add these permissions to a smaller
subset of users. You can do this as follows:
i. Create a group named OPC Users.
ii. Add all user accounts to this group.
The group will execute any OPC Server or Cli-
ent.
iii. Replace each occurrence of Everyone with OPC
Users. in the configuration dialogs.

6. Edit the Default Permissions for Access and for Launch and Activation.
For each user (or group) that participates in OPC communication (for example, OPC
Users), make sure that both the Local Allow and Remote Allow checkboxes are
selected.

Setting up DCOM on HSB server computers

To set up DCOM on HSB server computers:

1. Create a Windows user with same user name and password that are used to log in
to Windows in the workstation computer (computer where OpenRemoteDesktop is
used).
2. Start DCOMCNFG and find the list of registered COM servers (Component Services
-> Computers -> My Computer -> DCOM Config).
3. Select ABB MicroSCADA OPC DA Server properties (Action -> Properties).
4. On the Security tab, deny the remote 'Launch and Activation' and allow the remote
'Access' permissions to the client user.
5. Start DCOMCNFG and find the list of registered COM servers (Component Services
-> Computers -> My Computer -> DCOM Config).
6. Select OpcEnum properties (Action -> Properties). On the Identity tab, select
Launching user.
7. Start Local Security Policy (Control Panel -> Administrative Tools).
8. Select Local Policies -> User Rights Assignment. Make sure that the MicroSCADA
user has the Access this computer from the network permission.
9. Select Local Policies -> Security options.
10. Set Network access: Sharing and security model for local accounts to Classic -
local users authenticate as themselves.

How to solve DCOM problems

If you set the authentication level to Connect, verify that the server computer actually
belongs to the domain.

80
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

A standalone computer cannot authenticate the users unless

you have a matching user name and password on both the
client and server computer.

Check the access and launching permissions in Dcomcnfg and verify that the user logged
on to the client computer is explicitly included in these lists, or belongs to one of the
groups included.

You can use settings Control Panel -> Administrative Tools -> Local Security Policy
-> Audit Policy -> Audit logon events -> Failure = ON and Control Panel ->
Administrative Tools -> Local Security Policy -> Audit Policy -> Audit object access
-> Failure = ON to get error messages to Control Panel -> Administrative Tools ->
Event viewer about failing DCOM calls.

4.2.4.2. Configuring RDP session

You can configure a startup program for a RDP session.

1. Open the Remote Desktop Connection dialog and select the Programs tab.
2. Enter the full path and program name and the starting folder:
Program path and file name:
<drive letter>:\sc\prog\sa_lib\framewindow.exe

Start in the following folder:

<drive letter>:\sc\prog\sa_lib

Figure 4.2.4.2-1 shows the Remote Desktop Connection dialog with Monitor Pro as a
startup program.

For example, to open Classic Monitor, configure mons.exe with the path and correct
options as a startup program. See Opening Predefined Classic Monitor from the Command
Line for more information. In this case the path to the starting folder is <drive
letter>:\sc\prog\exec.

81
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

Rem_Desktop_Con.png

Figure 4.2.4.2-1 Remote Desktop Connection dialog

Opening Predefined Classic Monitor from the Command Line

A predefined classic monitor can be opened by running the mons.exe program together
with the -d parameter. The -d parameter excludes the use of parameters -s, -fl and -fr
from the command. A monitor is started with the following command:
mons -d <computer> <n>

where computer is the name of the base system computer where the predefined monitor
is defined, and n is the number of the predefined monitor as defined in the monitors.dat
file.

For Example, the command line:

mons -d mycomp 1

means that the predefined monitor number 1 defined on the base system computer
mycomp is opened. The settings of the monitor are taken from the monitors.dat file. The
4 possible values correspond to the values of the picture size listbox in the MicroSCADA
Monitor dialog. The VS font to be used in the opened monitor can be given from the
command line.

82
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

The options are "-fl font_local" and "-fr font_remote". These parameters are used for
changing the default font. The -fl parameter is used for setting the font of a VS local
monitor and the -fr parameter of a VS remote monitor.

For example:
C:\sc\prog\exec\mons.exe -fl "family:MS Sans Serif-size:12"

or
C:\sc\prog\exec\mons.exe -fr "family:Helvetica-size:12"

The command line parameter "-s number" selects the specified list element from the
"Picture Size:" -listbox to be the default picture size. The default value is 1. If given a
number greater than the amount that the listbox includes, i.e. 4, the default value is used.
The following command opens the MicroSCADA Monitor dialog with the value 1600
by 1200 as picture size:
mons -s 4

Monitors.dat

The monitors.dat file is a text file with a specified format. The default monitors.dat file
has the following contents:
[1]
SCS_MON_TYPE=LVS
SCS_MS_WINDOWS_APPLICATION=0
SCS_MS_WINDOWS_MONITOR=0
SCS_X_TERMINAL_FONT=family:MicroSCADA0810-size:10
DISPLAY=

[2]
SCS_MON_TYPE=MVS
SCS_MS_WINDOWS_APPLICATION=0
SCS_MS_WINDOWS_MONITOR=0
SCS_X_TERMINAL_FONT=family:MicroSCADA0810-size:10
DISPLAY=

[3]
SCS_MON_TYPE=RVS
SCS_MS_WINDOWS_APPLICATION=0
SCS_MS_WINDOWS_MONITOR=0
SCS_X_TERMINAL_FONT=-abb-scada-medium-r-normal--15-150-75-75-c-100-iso8859-1
DISPLAY=localhost:0
PRINTFILE=LPT1:

[4]
SCS_MON_TYPE=XMON
SCS_X_TERMINAL_APPLICATION=0
SCS_X_TERMINAL_MONITOR=0
SCS_X_TERMINAL_FONT=-abb-scada-medium-r-normal--15-150-75-75-c-100-iso8859-1
DISPLAY=localhost:0

83
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

4.3. Configuring process communication

The configuration of process communication is divided into the following configuration
tasks:

• Configuring communication system objects in base system

• Configuring process communication units (PC-NET, External OPC DA Client, CPI
applications)

In general, the process communication units cannot be created or accessed from any
application before the corresponding system objects in base system has been configured.
The definition method of these system objects depends on used process communication
unit type.

The required base system object types are as following:

• LINn:B object which defines a communication route from the base system to the
defined node
• NODn:B object which in this context defines the node of process communication
unit itself
• STAn:B object which defines a station within a defined node
• PRIn:B object which defines a printer within a defined node

If the used process communication unit is of type PC-NET and System Configuration
Tool is used, these base system objects are created automatically. If the System Config-
uration Tool is not used or the used process communication units are other than PC-NET,
see 4.3.2.2, Configuring IEC 61850 with External OPC DA Client - 4.3.2.5, Configuring
CPI-connected applications or to PC-NET start-up with SCIL commands in
4.3.2.1, Configuring PC-NET. System Configuration Tool supports only process com-
munication units of type PC-NET.

These objects can be also be configured using SYS_BASCON.COM or with SCIL using
statement #CREATE.

4.3.1. Configuring communication system objects in base system

The following system objects are needed for each process communication unit:

Links (LIN)

A link is a data transmission line to another base system, a NET unit or a device. Each
link is defined by a LINn:B object (n = 1 ... 20). A base system can have the following
links:

84
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

• One link of type LAN. The process communication unit may be directly connected
through LAN link. The LAN link is used between base systems and the process
communication unit may be connected to another base system (indirect connection).
• One link of type INTEGRATED for each configured PC-NET. This link type is
used only by PC-NET process communication unit and it is created by the System
Configuration Tool. The PC-NET.EXE process is started when the LIN:B object of
type INTEGRATED is created.

Node (NOD)

Nodes are directly or indirectly connected base systems and process communication
units. The nodes are defined by NODn:B objects (n = 1 ... 250). A node definition is
needed for:

• Communication to the communication units. Each process communication unit

which is recognized by the base system must be defined as a node. These node
definitions are described in System Objects manual.
• Reading and writing attributes. A node is primarily specified by the used connection
link and the station address of the node. If a node is only indirectly connected to the
base system, the link to the node is the link to the nearest intermediate node. The
link object must have been defined before the node can be defined.

Node definition is also used to define another base system in a network.

Example

A process communication unit uses LAN link and is configured to be node 3 and its
address is 203. The first step in the configuration is to create a LIN:B object of type
LAN (if not yet created for the base system communication).In this situation, the link
number can be selected. The next step is to create NOD3:B object for the process
communication unit and assign selected link number to the NOD3:BLI attribute of
the created object. The node address 203 is assigned to the attribute NOD3:BSA.

This configuration must be present before the process communication unit in node 3
can be accessed. For more information, on system objects of type NOD and LIN, see
SYS 600 System Objects. The process communication unit is PC-NET and System
Configuration Tool is used, these base system objects are created automatically,
otherwise the NOD and LIN need to be created with SCIL. The example above would
then require the following lines:

; LIN1:B OBJECT
#CREATE LIN:V = LIST(LT = "LAN", -
TR = "TCPIP")
#CREATE LIN1:B = %LIN
; NOD3:B OBJECT
#CREATE NOD:V = LIST(LI = 1, -
SA = 203)
#CREATE NOD3:B = %NOD

85
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

4.3.2. Configuring process communication units

The process communication unit types are listed below:

• PC-NET
• External OPC DA Client
• CDC-II slave
• Modbus slave
• Other CPI-connected applications

Most of the communication protocols are supported by the PC-NET process communic-
ation unit. For more information on attribute PO and a complete list of protocols, see
SYS 600 System Objects. Communication unit of type External OPC DA client is used
with OPC connected protocols such as IEC61850. External OPC DA client, CDC-II
slave, Modbus slave and other CPI-connected applications. LAN link is used as the
communication route between base system and the communication unit.

4.3.2.1. Configuring PC-NET

The recommended way to configure process communication unit of type PC-NET is to

use System Configuration Tool. While creating the full configuration, it provides a set
of possible selections in each step. In practice, these selections are mainly protocol specific
line type and station types. It is also possible not to use the System Configuration Tool
and create the line and station configuration using SCIL. The protocol specific manuals
contain examples of how this is done with each protocol. This method is often used when
a MicroSCADA system is updated to a newer release and the amount of changes to the
system is tried to minimize.

When the PC-NET program is started, it reads the initial configuration file PC_NET.CF1,
which is a text file located in the \sc\sys\active\sys_ directory. It defines the basic
communication nodes and addresses to enable the communication to an application that
downloads the total configuration.

When a PC-NET configuration is created with the System Configuration Tool, the tool
produces two data files: SYSCONF.INI and SIGNALS.INI. When the system is started,
it reads the mentioned files and creates a file PC_NET.CF1 automatically. To create
system objects, the System Configuration Tool automatically creates the file
SYS_BASE.SCL, which is executed at system start-up. After the PC-NET has started,
the system executes the file SYS_NET.SCL to configure the PC-NET. The file is auto-
matically created by the System Configuration Tool. A step-by-step description of the
System Configuration Tool operation is described in Section, PC-NET Startup with
System Configuration Tool. This information is rarely needed, and in practise the system
configuration can be entered and controlled without knowledge of the internal operation
of the tool.

86
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

Start-up definition file PC_NET.CF1

When PC-NET process starts, it always reads the start-up configuration file PC_NET.CF1.
This file is generated automatically by the System Configuration Tool. If the configuration
is loaded with SCIL, it may be necessary to edit this file. The following PC_NET.CF1
file is included in the MicroSCADA Pro Control System SYS 600 delivery as a default
configuration:
local_node.sa=203 ; The station address of the PC-NET.
local_node.nn=3 ; The node number of the PC-NET.
ext_node(1).sa=209 ; The station address of the base system.
ext_node(1).nn=9 ; The node number of the base system.
ext_apl(1).nn=9 ; The node number of the base system.
ext_apl(1).an=1 ; An application in the base system.

In case the PC_NET.CF1 file is missing when the PC-NET is started, a default configur-
ation becomes valid.

PC-NET start-up with System Configuration Tool

The information given in this chapter describes the internal operation of the System
Configuration Tool. Usually, this is transparent for the user.

The System Configuration Tool creates procedures for automatic start-up and configur-
ation of the PC-NET. The automatic starting/configuration can be switched on or off.
Manual starting/stopping of the PC-NET can be done in online mode. The automatic
starting and configuration of the PC-NET works in the following way:

• A command procedure SYS_INIT_1:C is connected to the event channel

APL_INIT_1:A as the first secondary object. If the list of the secondary objects is
full, the last one is removed and a warning is generated (notify window, log file).
• The command procedure SYS_INIT_1:C calls a text file (StartPC-NET.SCL) which
starts the PC-NET. The program in the text file first updates the sys_/PC_NET.CF1
file and then starts the PC-NET by setting the corresponding base system link object
type to INTEGRATED. The PC_NET.CF1 file is updated in the following way:

The PC-NET sends a system message to the own application when it is started. This
message is received by a process object to which an event channel,
SYS_NET'net_number'D:A, is connected. This event channel calls a command procedure
SYS_NET'net_number'D:C. If the process object exists (for example created by LIB5xx)
and has an event channel connected to it, all the objects connected to that event channel
is moved to the SYS_NET'net_number'D:A event channel as secondary objects. In other
cases, the System Configuration Tool automatically creates a process object
SYS_NETD:P('net_number'), to which the event channel SYS_NET'net_number'D:A
is connected.

87
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

The command procedure SYS_NET'net_number'D:C checks

the message coming from the PC-NET. If this is the start
message (10001), the PC-NET is configured according to the
information entered in the System Configuration Tool.

If the system configuration contains many PC-NETs, then for each of the PC-NET pro-
cesses to be started by System Configuration Tool, an instance specific copy of
PC_NET.CF1 file can be found from the same folder. These files follow the file naming
convention DEBUG'net_instance_number'.CF1, for example, file name DEBUG1.CF1
is used for the first PC-NET process instance.

All the possible error messages that occur during the start-up or configuration of the PC-
NET are shown in the notify window. They are logged into the SYS_ERROR.LOG and
SYS_ERROR.OLD log files, which can be viewed using some text editor of Windows
operating system.

PC-NET start-up with SCIL commands

A command procedure for online reconfiguration of PC-NET can be started as follows:

• When a PC-NET unit is restarted, it sends the system message 10001 to all the
defined applications (by default to process object address 6000 + NET no), provided
that the application is running. The system message can be used for updating a
process object which activates an event channel, which in turn starts a command
procedure with reconfiguration commands. For more information describing the
System messages from PC-NET units, see System messages - base system configur-
ation and System Messages - PC-NET configuration described later in this section.
• When the connection between PC-NET and an application recovers after a break,
PC-NET sends the system message 1000 + APL no. to the application (by default
to address 6050 + NET no.). This message can be used for conditional start of
reconfiguration procedures, that is, reconfiguration takes place if PC-NET has been
restarted, not if the application has been out of use. This can be checked for example
by reading a system object attribute configured online. If online configuration
changes are valid, PC-NET has not been out of operation.

Reconfiguration commands could also, for example, be included in the command pro-
cedures started by the event channels APL_INIT_1 and APL_INIT_2, (APL_INIT_H
in hot stand-by systems, see SYS 600 Application Objects). However, a PC-NET unit
can be restarted even though the application is not restarted.

The protocol specific manuals contains examples for the configuration script for each
protocol. In principle, following step are needed for every protocol:

1. Define the NET line to be used by assigning it the wanted protocol.

2. Give the line its communication properties by means of the line attributes.

88
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

3. Create the station(s) by giving it an object number and assigning it the line number.
4. Set the attributes of the created object.
5. Take the line and the device into use.

In SCIL, communication system objects are created and deleted using NET attributes,
see SYS 600 System Objects. When adding a device, the NET line should first be defined.
NET lines are defined by the NET line attribute PO. The used hardware device is generally
defined with attribute SD, which, for example, may refer to certain serial port or PCLTA
card.

Defining external nodes (NET)

All the connected base systems and communication units are defined as external nodes
(NET objects). This applies also to base systems and communication units, which are
only indirectly connected via other communication units.

The primary external node, that is, the PC-NET that communicates via integrated link
is defined in PC_NET.CF1 file and the corresponding attribute values are updated . If
there is a need to define other nodes, the configuration of NET node attribute NE need
to be configured.

Defining applications (APL)

As a rule, all the applications in all base systems, which are directly or indirectly connec-
ted to the communication unit, should be defined to the NET unit as APL objects. The
defined applications can be configured to receive spontaneous messages from the stations
and system messages generated by NET.

In order to define or redefine an application in a connected base system:

1. Define an “Application”, an APL object, in the preconfiguration or online by means

of the NETn:SSY attribute. For more information, see SYS 600 System Objects.
2. Assign it to the following attributes for the communication supervision. For more
information, see SYS 600 System Objects.

From SCIL, the SW and SU attributes are accessed as NETn:S attributes. NET supervises
all its application connections by cyclically reading the DS attribute of all known
applications at the interval calculated from the SU attribute. If an application does not
reply, an error message is produced and the application is suspended. This happens when
the base system is closed, when the application has been set to COLD, the application
does not exist, or the connection is faulty or disturbed, or the communication does not
work. When an application has been suspended, the RTUs connected to that application
are not polled until the communication with the application has been re-established.

If the defined application is not running in a base system directly connected to the PC-
NET but is running in another node, the NOD:B and LIN:B objects should define the

89
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

route to the destination node. This route is usually a LAN link, but this may also be a
serial line ACP.

Online configuration changes

The online configuration changes can be done in the online mode of the System Config-
uration Tool, with SCIL from a Test Dialog or from a command procedure.

The online changes take effect immediately. However, if the PC-NET unit is stopped
and restarted, the online changes are lost and the preconfiguration is restored. Online
changes which need to be permanent, and are not made in the preconfiguration, should,
therefore, be included in a command procedure which is executed each time the PC-NET
unit is restarted.

When SCIL is used, the attributes are accessed with the object notation according to the
format:

OBJnn:Sati
Table 4.3.2.1-1 Object notation table
'nn' Object number (device number)
'at' Attribute name
'i' The possible index

OBJ in this context may be STA referring to a station object or PRI referring to a printer
object. For more detailed information about the object notation, see SYS 600 System
Objects.

The attributes are written with the #SET command according to the format:
#SET OBJnn:SATi = value

The line attributes can be changed with the SCIL command #SET:
#SET NETnn:Sati = value
'i' Line number

For detailed information on each attribute, see SYS 600 System Objects or protocol-
specific configuration manuals.

System messages - base system configuration

To use the system messages in an application, follow the instructions given below:

90
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

1. Create a fictitious process object of type ANSI analog input and set the Unit Number
(UN) attribute to 0. The system message codes of the device is registered as the
object value of this object.
2. Set the objects Object Address (OA) attribute equal to the Message Identification
(MI) attribute and set the Switch State (SS) attribute to Auto.
3. Select direct scale (1-1).

Define the consequential operations by using the event, alarm and printout attributes.
For more information on alarm generation, activation of event channel and automatic
updating in pictures, for printout activation and for including event history in the event
list, see SYS 600 Application Objects.

The default values of MI attributes for each station type are presented in the System
Objects manual and in the protocol specific manuals. The defaults listed below are pro-
tocol independent:
Table 4.3.2.1-1 Message Identification (MI) default value table
Object Message MI default value

NET itself General messages, for 6000 + NET no.

example start-up messages

Value: status code

Application supervision 6050 + NET no.

Value: APL no.= failure

1000 + APL no. = recovery

(APL no. as known to NET)
NET line All NET line messages 6000 + 100 NET no. + line no.

System messages - PC-NET configuration

When a system message is caused by a system object, it is directed to the application

specified by the Message Application (MS) attribute of the object. The code of the
message is updated as the object value for a fictitious process object with the Object
Address (OA) attribute value equal to the value of the Message Identification (MI)
attribute.

To achieve the system message handling in the communication unit:

1. Set the Message Application (MS) attribute of the system object to the number of
the receiving application.
2. Set the Message Identification (MI) attribute of the system object to the value of
object address of the receiving object. The MI attribute has object dependent default
values which are also the recommended values, and should generally not be changed.
The default value is used when the system object is defined online and the MI
attribute is not explicitly set, or if the MI attribute is set to 0 in the preconfiguration.

91
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

The default values are shown in the Table 4.3.2.1-1 above, in the System Objects
manual and protocol specific manuals.

The transmission of system messages from individual objects can be enabled or disabled
by the System Message Enabled (SE) attribute of the objects. The system message gen-
eration should only be disabled in special cases, for example, if the base system applica-
tion program often executes commands, which cause unwanted system messages.

The SE attribute exists for the PC-NET Node and it is accessed by NETx:SSE. This
attribute controls the transmission of the system messages from all objects configured
to the node. This attribute can also be used to enable the updating of the binary status
points.

4.3.2.2. Configuring IEC 61850 with External OPC DA Client

External OPC DA Client and IEC 61850 OPC Server are included as a separate execut-
ables in the the SYS 600 product. External OPC DA Client is communicating to SYS
600 base system via LAN link and acting as one communication node in a MicroSCADA
network. In other words, the related base system objects has to be created in the
SYS_BASCON.COM file and the OPC namespace of the IEC 61850 OPC Server has
to be mapped into process objects. The required station type for units is "SPA". The
mapping between OPC items and process objects is done in External OPC DA Client
Configuration Tool.

For description of the different topologies and configuration details of this IEC 61850
communication, see SYS 600 IEC 61850 System Design. Otherwise, the configuration
of External OPC DA Client has been described in SYS 600 External OPC Data Access
Client and IEC 61850 Server in SYS 600 IEC 61850 Master Protocol OPC.

4.3.2.3. Configuring CDC-II slave

CDC-II slave protocol is also supported by a separate executable which is connected to

base system via LAN link. The configuration of the base system objects described in
4.3.1, Configuring communication system objects in base system, are needed before the
communication between base system and the CDC-II slave executable is established.
The required station type is "RTU".

For a description of the configuration details of this process communication unit type,
see SYS 600 CDC-II Slave Protocol User’s Guide.

4.3.2.4. Configuring Modbus slave

Like CDC-II, Modbus slave protocol is also supported by a separate executable which
is connected to base system via LAN link. The configuration of the base system objects
described in 4.3.1, Configuring communication system objects in base system are needed

92
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

before the communication between base system and the modbus slave executable is
established.

For description of the configuration details of this process communication unit type, see
SYS 600 Modbus Slave Protocol.

4.3.2.5. Configuring CPI-connected applications

CPI (Communication Programming Interface) is a software library for connecting an

application to the MicroSCADA base system. Each application instance using CPI as
an interface is seen as node in SYS 600 network and corresponding NODx:B and LINx:B
need to be created.

For a description on how the CPI interface is used and how the application instance is
seen from the base system, see SYS 600 Communication Gateway, COM 500i User's
Guide.

4.3.2.6. Selected configuration examples for PC-NET

Base system network using serial ACP

For performance reasons, generally there should not be more than three communication
units in a series between a base system and a communicating device. These are base
system, workplace, printer or RTU.

When communication units and base systems are connected to a network, each NET unit
and each base system in the network should be defined as a node in each other’s NET
unit and base system.

In order to connect two communication units through serial lines make the following
definitions in each of the unit:

1. Select a line for the connection and define it with the ACP protocol as follows:

PO 1
MS System message application
MI System message object address
BR Baud rate
PY Parity
SB Number of stop bits
RD Read data bits
TD Transmission data bits
ER Embedded response

93
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

RE Redundancy
TI Time-out length in seconds (1 + 2400/BR)
NA NAK limit
EN ENQ limit
PS Buffer pool size

The communication attributes (BR, and so on) should have the same values as the cor-
responding parameters in the connected communication unit. If the NET is a PC-NET,
the line numbers 1...4 are available. These lines corresponds to the COM ports. When
selecting one of these lines for the ACP protocol (setting the PO attribute of the line to
1), the line number cannot be used for any of the LON channels.

2. Define an "External node", a NET object, on the ACP line for the connected commu-
nication unit:

Device type NOD

Device number The node number of the connected communic-
ation unit
LI, Line number The number of the selected line
SA Station address of the connected communica-
tion unit

Though two communication units are connected indirectly via another unit, they should
be defined to each other. Make the following definitions in each of the units.

3. Define an "External node" (NET object) connected to the line to the nearest commu-
nication unit:

Device type OD
Device number The node number of the indirectly connected
communication unit
LI, Line number The line to the nearest NET unit in the series
SA Station address of the indirectly connected
communication unit

Each NET unit which is connected to a base system via one or more other units should
be defined to the base system as a node (NODn:B objects):

1. Create a NODn:B base system object corresponding to the indirectly connected com-
munication unit. The NOD object number ('n') should be the same as the node number
of the communication unit. The NOD object is given the following attribute values:

LI Link number (= LIN object number)

This is the link to the nearest communication
unit

94
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

SA Station address of the indirectly connected

communication units

Even if there is no communication between the base system and the indirectly connected
NET, the node definition is necessary for the system diagnostics, online configuration
and system maintenance.

2. Define an "External node" (NET object) on the line to the nearest communication
unit:

Device type NOD

Device number The node number of the indirectly connected
base system
LI, Line number The line to the nearest communication unit in
the series
SA Station address of the indirectly connected base
system

3. Define an application for each application in the indirectly connected base system.

Figure 4.3.2.6-1 shows an example of a network of two communicating NETs and two

base systems. The table below shows the configuration of the NETs and base systems.
The example includes only the definitions which are of importance for this particular
configuration and which have not been described in the previous sections.

95
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

A051805

Figure 4.3.2.6-1 Example of a configuration with interconnected base systems and NETs

Configuration of Communication unit 1

See Figure 4.3.2.6-1.
External node 9 (Base system 1)
Device type: NOD
Device number: 9
LI Line number: 13
IU In use: 1
SA Station addr. (Dec.): 209
Application 1
Device type: APL
Device number: 1
Translated APL number: 1
Node number: 9
IU In use: 1
SW Reply timeout: 5
SU Suspension time: 60
Configuration of Communication unit 2
See Figure 4.3.2.6-1.

96
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

Line 2 (ACP line)

PO Protocol 1
IU In use: 1
MS Message application: 1
MI Message ident: 6202
LT Link type: 1
BR Baud rate: 9600
SB Stop bits: 1
PY Parity: 2
RD Receiver data bits: 8
TD Transm. data bits: 8
RE Redundancy: 2
TI Timeout length: 3
NA NAK limit: 3
EN ENQ limit: 3
ER Embedded response: 1
RP Reply poll count: 1
PS Buffer pool size: 30
External node 3 (Communication unit 3)
Device type: NOD
Device number: 3
LI Line number: 2
IU In use: 1
SA Station addr. (Dec.): 203
External node 9 (Base system 1)
Device type: NOD
Device number: 9
LI Line number: 13
IU In use: 1
SA Station addr. (Dec.): 209
External node 11 (Base system 3)
Device type: NOD
Device number: 11
LI Line number: 2
IU In use: 1

97
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

SA Station addr. (Dec.): 211

Application 1
Device type: APL
Device number: 1
Translated APL number: 1
Node number: 9
IU In use: 1
SW Reply timeout: 5
SU Suspension time: 60
Application 5
Device type: APL
Device number: 5
Translated APL number: 5
Node number: 11
IU In use: 1
SW Reply timeout: 5
SU Suspension time: 60
Configuration of Communication unit 3
See Figure 4.3.2.6-1.
Line 3 (ACP line)
PO Protocol: 1
IU In use: 1
MS Message application: 5
MI Message ident.: 303
LT Link type: 1
BR Baud rate: 9600
SB Stop bits: 1
PY Parity: 2
RD Receiver data bits: 8
TD Transm. data bits: 8
RE Redundancy: 2
TI Timeout length: 3
NA NAK limit: 3
EN ENQ limit: 3
ER Embedded response: 1

98
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

RP Reply poll count: 1

PS Buffer pool size: 30
External node 2 (Communication unit 2)
Device type: NOD
Device number: 2
LI Line number: 3
IU In use: 1
SA Station addr. (Dec.): 202
External node 9 (Base System 1)
Device type: NOD
Device number: 9
LI Line number: 13
IU In use: 1
SA Station addr. (Dec.): 209
Application 1
Device type: APL
Device number: 1
Translated APL number: 1
Node number: 9
IU In use: 1
SW Reply timeout: 5
SU Suspension time: 60
Application 5
Device type: APL
Device number: 5
Translated APL number: 5
Node number: 11
IU In use: 1
SW Reply timeout: 5
SU Suspension time: 60

Configuring stations using RP570 master protocol

Base system configuration

99
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

In order to connect SYS 600 network to RTUs with RP570 protocol, the following
definitions are required in the base system, which uses the station:
1. Create a STAn:B object with the following attributes:

ND The node number of the NET unit to which the RTU directly connec-
ted.
ST RTU
TN Corresponding STA object number in the communication unit.
TT EXTERNAL

For more information on the attributes, refer to the System Objects manual.
The STAn:B object definition is not necessary, if the default station type defined
by SYS:BDS is RTU and the default node defined by SYS:BDN is the NET unit to
which the RTU is connected and the mapping is direct.
However, if no STAn:B object is defined, the station cannot be handled by the
MicroSCADA Pro tool pictures.
2. If needed, map the station for the application which uses it with the APLn:BST
attribute. Station mapping is necessary only if the logical number is another than
the STAn:B object number, which is the default mapping.
The logical station number is the Unit Number (the UN attribute) of the process
objects defined for the station. For more information, refer to the System Objects
manual.

PC-NET configuration

Perform the configuration definitions described below in the NET unit to which the station
is directly connected. It is assumed that the NET unit has been defined to the base system
as a NODn:B object, and that the base system has been defined to the NET unit as an
external node.

1. Select a line for the station (several RTUs can be connected to the same line) and
define it with the RP 570 protocol:

PO 7
LT 0 (RS232) or 1 (modem line)
IU 1
MS The application receiving system messages
MI The object receiving system messages
BR Baud rate, should be the same as in the RTU
PY 2
RD 8
TD 8
SB 1

100
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

PS Buffer pool size

DE CTS delay in milliseconds
EN Enquiry limit time in milliseconds
PD Poll delay in milliseconds
PP Polling of suspended stations
RP Number of consecutive polls
TI Timeout length in seconds
HT Timeout in milliseconds for start of response reception (default =
700 ms)
RI Time delay in milliseconds before enabling a line after a message.
Default = 0. A time delay should be used, if NET's transmission
echoes back into the receiver.
RK RTS keep up padding characters, refer to the System Objects
manual

2. Make sure that the application which receives spontaneous messages from the station
(the station attribute AS) is defined as an APL object.
3. Define a station of type RTU connected to the RP 570 line:

Device type 4
LI Selected line number
AL 1
AS The number of the connected application
MS The application receiving system message
MI The object receiving system messages
SA RP570 station address (= the address in the RTU)
RT Reply timeout in seconds

If several stations are connected to the same line, define the stations with the same
line number (LI).
The NET unit recognizes an automatically created "station", STA0, as "broadcast
station". The broadcast station notates all S.P.I.D.E.R. RTUs connected to the same
NET.
4. Synchronize the RTU200 clock with the clock of the NET unit at start-up by setting
the SY attribute, for example, #SET STAn:SSY (supposing that the NET clock has
been synchronized before). By using the broadcast station number, all RTUs con-
nected to one NET can be synchronized simultaneously.
5. If needed, change the AW attribute of the RP 570 line (refer to the System Objects
manual). This is normally not necessary.

A SYS 600 revision beginning with 8.2B supports the configuration of hierarchical RTU
structures. Define the sub-RTUs as STA objects in NET and in the base system, in the
same way as an RTU connected directly to NET as described in the manual. The only

101
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

difference between the directly connected RTUs and sub-RTUs is the STAn:SHR
attribute, refer to the System Objects manual. For STA objects corresponding to sub-
RTUs, the HR attribute is the station address of the RTU one level above in the hierarchy.

The data of ERMFD and ERMIR telegrams is converted into bit stream values, which
are sent to the process database.

In order to register the data in the process database, define bit stream type process objects
with the following object addresses:

For ERMFD : 2304 + block nr

For ERMIR : 1792 + block nr

ERMFD data coding in process object

Bit stream object value:

bytes 1..4: VALUE (least significant byte first)

byte 5: STATUS with time quality and so on, copied
from RP 570 telegram
bytes 6..7: RELATIVE TIME (least significant byte first)
bytes 8..9: NUMBER (least significant byte first)
byte 10: CAUSE OF TRANSMISSION
byte 11: FORMAT
Registration time: stored in RT attribute as nor-
mal

ERMIR data coding in process object

Bit stream object value:

byte 1: VALUE (least significant byte first)

byte 2: BIT NUMBER
byte 3: INDICATION TYPE
byte 4: STATUS with time quality and so on, copied
from RP 570 telegram
bytes 5..6: RELATIVE TIME (least significant byte first)
bytes 7..8: NUMBER (least significant byte first)
byte 9: CAUSE OF TRANSMISSION
Registration time: stored in RT attribute as nor-
mal

The coding of each field, when not explicitly described above, follows the RP 570 tele-
gram.

102
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

There are two methods of building an RTU configuration. The RTU configuration can
be performed independently of SYS 600, which means, the SYS 600 process object
definition is built separately with no help from the RTU configuration files. Alternatively,
the RTU configuration can be built via SYS 600, which means, the SYS 600 engineer
can use the configuration in the process object definitions. Changes in the SYS 600
process database can then be loaded down to the RTUs.

RTU configuration

It is recommended to build the RTU configuration via MicroSCADA Pro.

To build the RTU configuration:

1. Use the EDU (Engineering and Diagnostic Unit) tool, that is the RTU configuration
tool for RTU engineering. The RTU configuration is stored in key files. When using
EDU, a file conversion is required.
2. Define the process database objects in the MicroSCADA Pro system using the key
files.
3. Download the complete configuration to the RTU, including possible changes made
in the SYS 600 process database.

Loading the RTU configuration

If your RTU is connected, you can now load the configuration, or you can use the process
definition tool to make changes in the definitions. To do this, select Other Choices >
Download > Start.

Configuring stations using ANSI X3.28 protocol

Base system configuration

Connecting a station using the ANSI X3.28 protocol (ANSI station) to the SYS 600
network requires the following definitions in the base system which uses the station:

Create a STAn:B (n = 1 ... 2047) object with the following attributes:

ND The node number of the NET unit to which the station is directly connected.
ST "STA"
TN STA object number in the NET unit.
TT "EXTERNAL"

The STAn:B object definition is not necessary if the default station type, defined by
SYS:BDS, is STA and the default node, defined by SYS:BDN, is the NET unit to which
the station is connected to and if the mapping is direct.

If needed, map the station to the application which uses it with the APLn:BST attribute.
Station mapping is necessary only if the logical number is other than the STAn:B object
number, which is the default mapping. The logical station number is the Unit Number

103
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

(the UN attribute) of the process objects defined for the station (refer to the System
Objects manual).

Configuration for SRIO device

SRIO system parameters

By changing the SRIO 1000M system parameter values, the application programmer
can affect general features of the SRIO 1000M program. The system parameters are
located in the address area from 3000 upwards.

Table 4.3.2.6-1 shows some examples of system parameters, each of which occupies

one word. For further information about SRIO system parameters, refer to the SRIO
manuals.
Table 4.3.2.6-1 Examples of systems parameters
Word 0 (address 3001): Spontaneous event data transmission
1 = Enabled
0 = Disabled
Word 1 (address 3002): Spontaneous transmission of changed data in database
1 = Enabled
0 = Disabled
Word 2 (address 3003): Store command
1 = Start storing the configuration data into EEROM
0 = No meaning
Word 3 (address 3004): Analog data format
0 = 32 bit integer
1 = 3-digit BCD
2 = 6-digit BCD
Word 4 (address 3005): Analog data scaling
1, 10, 100, 1000 (default) or 10000
Word 5 (address 3006): Time polling interval
30 .. 30000 seconds (default = 60 s)

#SET STA1:SME3001=0

Disable spontaneous process data transmission.

#SET STA1:SME3002=1

Store SRIO 1000M configuration data into EEROM memory.

#SET STA1:SME3003=1

104
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

Analog values to be coded as 3-digit BCD numbers.

SRIO object parameters

The SRIO object parameters allow the MicroSCADA Pro applications to read and write
the definitions of data items, data groups and event data polling.

The start address of object parameters is 5000 in the default configuration. SRIO can
contain up to 500 objects.

The following attributes are defined for each data item (start address refers to the start
address within the object parameter area, that is add 5000 to each address):

Attributes Start address

ANSI address 0
Bus number 500
SPACOM address 1500
Data type/format 4500
Delta value/bit mask (32 bits) 5500
Status word (16 bits) 6500

Example

A SCIL command procedure for the creation of an AI type SRIO object:

Defining variables
@OBJ_IND = Object nr (index) in the SRIO database
@ANSI_A = Object address in the MIcroSCADA database
@BUS = Bus number
@SPA_A = SPA address as a 6 word vector (see the SRIO manuals)
@DTYPE = Data type
@DFORM = Data format
@DELTA = Delta value
@STATUS = Status word as an integer

Defining constants
@OB_PAR_I = 5000
@ANSI_A_I = %OB_PAR_I
@BUS_I = %OB_PAR_I + 500
@SPA_A_I = %OB_PAR_I + 1500
@DATA_T_F_I = %OB_PAR_I + 4500
@DELTA_I = %OB_PAR_I + 5500
@STATUS_I = %OB_PAR_I + 6500

Creating object
#SET STA1:SME (%ANSI_A_I+%OBJ_IND) = %ANSI_A
#SET STA1:SME (%BUS_I+%OBJ_IND) = %BUS

105
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

@SPA_STADR = %SPA_A_I + 6 * %OBJ_IND

#SET STA1:SME (%SPA_STADR..(%SPA_STADR+5)) = %SPA_A
@D_T_F_ADR = %DATA_T_F_I + 2 * %OBJ_IND
@DATA_T_F(1) = %DTYPE
@DATA_T_F(2) = %DFORM
#SET STA1:SME (%D_T_F_ADR..(%D_T_F_ADR + 1))=%DATA_T_F (1..2)
@DELTA_S_A = %DELTA_I + 2 * %OBJ_IND ;32-BIT ADDRESS
#SET STA1:SME (%DELTA_S_A) = %DELTA
#SET STA1:SME (%STATUS_I+%OBJ_IND) = %STATUS

A data group can consist of 10 data items, and there can be up to 100 data groups. The
data group definition tells the ordinal numbers of the data items in the group. The data
group definitions are found from the address (7000 + object parameter area start address).
Above is an example of a SCIL command procedure which defines a data group.

The event data polling can cotain up to 300 SPA bus slave units (100 slaves/bus). In the
address range starting from 8000 + object parameter area start address. The following
features of each object to be event polled are defined:

• Bus number
• Unit number
• Unit type
• Status

Examples of creating a SRIO data group with SCIL

Defining variables
@GROUPNR = Number of the group to be created
@MEMBERS = Vector containing the ordinal numbers of the group members
in the SRIO 1000M database.

Defining constants
@GROUPDEFSA = 12000
@GROUPLEN = 10

Creating the data group

@MEMBCOUNT = LENGTH (%MEMBERS)
@STARTADR = %GROUPDEFSA + %GROUPNR * %GROUPLEN
@ENDADR = @STARTADR + %MEMBCOUNT - 1
#SET STA1:SME (%STARTADR..%ENDADR) = %MEMBERS

Auto-dialling in serial protocols

Auto-dialling can be used on all NET serial lines with the following protocols:

• ANSI X3.28 Half Duplex or Full Duplex protocols

• ACP (Application Communication Protocol)
• Modbus

106
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

• Alpha
• 61107
• IEC
• RP 570 master and slave
• SPA
• IEC 60870-5-101 master and slave
• IEC 60870-5-103 master
• DNP 3.0 master and slave

The example below describes the configuration using SCIL. The usage of the System
Configuration Tool is possible and recommended.

Auto-dialling is useful for the following reasons:

• For the connection of remote stations with infrequent data transfer

• For the connection of home terminals
• For taking a reserve line into use

Auto-dialling is possible in both directions.

The auto-dialling line can be defined in the preconfiguration. However, the auto-dialling
feature cannot be preconfigured, it should be configured and taken into use online.

Create the line in the preconfiguration or online. Depending on the device(s) connected
to the line, set the Protocol (PO) attribute to 1 for the ANSI X3.28 Full Duplex protocol,
2 for the ANSI X3.28 Half Duplex protocol, 25 for Modbus RTU mode master protocol
and 26 for the IEC 61107 protocol.

The auto-dialling feature for a line can be added by using a tool or SCIL. The dial-up
modem has to be connected to the line while defining the auto-dialling feature.

To define the auto-dialling with SCIL:

1. Take the line out of use by setting the In Use (IU) attribute of the line to 0, for
example:
#SET NET1:SIU5 = 0

2. Set the ACE (AC) attribute of the line to 1, for example:

#SET NET1:SAC5 = 1

3. If the NET unit is supposed to answer incoming calls which is always the case on
RP 570 lines, set the Remote Calls Enabled (RC) attribute to 1, for example:
#SET NET1:SRC5 = 1

4. If an automatic break of the connection is wanted after a specified time, set the
Connection Time Limited (CL) and Connection Time (CT) attributes, for example:

107
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

#SET NET1:SCL5 = 1

#SET NET1:SCT5 = 500

which means that the connection is broken automatically after 500 seconds.
5. If needed, set the Radio Disconnection Delay (DD), Pulse Dialling (PU), Radio
Connection Wait Time (RW) and ACE AT S Register (SR) attributes. See SYS 600
System Objects.
6. Set the In Use (IU) attribute of the line to 1, for example:
#SET NET1:SIU5 = 1

To dial up a workplace or RTU from a NET:

Set the Connection (CN) attribute in an application program as follows:

#SET NETn:SCNline = "phone"

or when dialling a station:

#SET NETn:SCNline = "phoneSstation"

where

line Line number

phone Phone number of the receiver
station Station number of the receiver

Dialling is done while the line is in use (IU = 1).

When the NET is dialling, system messages with codes 16107, 16208 or 16825
(depending on the protocol) are generated. If a station is dialling, the codes 16108, 16209
or 16826 are generated. A failed dial-up generates the code 16704.

The connection to an RTU is broken automatically, under the following circumstances:

• RTU becomes inoperable

• RTU hangs up
• when the RTU is the dialling part
• RTU has nothing to send (after two subsequent CCR2 responses)

In addition to these, the connection can be broken automatically according to the Con-
nection Time (CT) attribute. If the connection is not broken automatically, break it by
setting the Connection (CN) attribute to 0:

#SET NETn:SCNline = 0

108
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

A succeeded hang-up generates a system message with code 16733. If the hang-up failed,
the code 16702 or 16703 is generated. The status codes 16106, 16107 and 16810 indicate
that disconnection has started.

Example

Dialling a MicroTERMINAL:

#SET NET1:SCN5 = "1234567"

Dialling station 11 (STA11):

#SET NET1:SCN5 = "1234567S11"

Breaking the connection:

#SET NET1:SCN5 = ""

4.3.3. Distributed process communication units

In principle, the process communication unit may be directly connected to any base
system node in MicroSCADA Pro network. The application containing the corresponding
process database, may be in another base system node and all data sent from the process
communication unit is transmitted through the LIN objects between these nodes. The
used protocol is ACP (Application Communication Protocol). The base system between
the process communication unit and the upper base system routes the ACP messages in
both directions. The STAn:B objects are created to both to the routing base system and
to the base system running the database.

A commonly used system setup is based on the distribution of PC-NET process commu-
nication unit to separate computers. In this configuration, the primary link between the
base systems is a LAN link. For more information on this configuration, see
4.3.3.1, Distributed PC-NETs.

If the process communication unit is configured to contain slave protocols, in general it

is recommended that the unit is directly connected to the base system which contains
the application receiving the process data. In other words, it is not recommended that
for example the COM 500I application refers to STAn:S objects running in another
computer.

4.3.3.1. Distributed PC-NETs

There are many reasons why it is necessary to divide the PC-NETs to operate in a separate
computer or multiple separate computers:

109
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

• Computer hardware limitations of LON or serial cards

• Decreasing the problems caused by a computer failure
• Process communication causes CPU load
• Redundancy is required in the process communication level

The base system which is directly connected to the PC-NET usually contains no process
database. Figure 4.3.3.1-1 presents the system containing a hot stand-by base system
containing a process database and three separate computers for process communication.
In the system, the CPU load caused by the process communication is divided to three
CPUs. Furthermore, if a hardware failure occurs in some of the computers, the rest of
the system is still under control.

A070472

Figure 4.3.3.1-1 PC-NET configuration

The communication front-end base systems SYS21..SYS23 running APL11..APL13

only routes the ACP messages between PC-NET nodes and APL1. In the system start-
up or in the hot stand-by switch the APL1 is defined to be in either of the base systems
containing the database.

Figure 4.3.3.1-1 describes a situation, in which there is only one PC-NET running in

each computer. In practice, each of these computers may contain multiple PC-NET
instances and various set of lines using different protocols. Furthermore, each of these

110
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

computed may also be doubled using hot stand-by configuration. The watchdog APL
object needed in hot stand-by configuration is APL2.

At the process database level, the system may also contain mirroring.

The System Configuration Tool should be used in each of the computers running the
PC-NETs. The configuration in the base system running APL 11 could be the same as
presented in Figure 4.3.3.1-2.

A071353

Figure 4.3.3.1-2 System Configuration Tool

The corresponding STAn:B objects should be configured to the base systems containing
the process database. The selected part from the SYS_BASCON.COM file for the system
described above would be:
.
.
;
;Other Base System Nodes
;
#local NOD_Numbers = vector(21,22,23),- ;for example vector(11,12),-
NOD_Names = vector("10.10.10.21","10.10.10.22", "10.10.10.23"),-
NOD_Addresses = vector(221,222,223)

.
.

;
;Gateway Nodes
;
#local GW_NOD_Numbers = vector(1,2,3),- ;for example vector(20,22),-

111
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

GW_NOD_Addresses = vector(201,202,203)

.
.

;An example of STA object definitions for NCC level (MR = "IMAGE") stations in
the following
;

#local Stations = ( 10, 11, 13, 14, 15, 16 )

#local Sta_ST = ( "LMK", "SPA", "REX", "REX", "REX", "REX" )
#local Sta_Nodes = ( 1, 1, 1, 1, 1, 1 )
#local Sta_MR = ( "NONE", "NONE", "NONE", "NONE", "NONE", "NONE" )
#local Sta_H_Apl = ( 0, 0, 0, 0, 0, 0 )
#local Sta_H_UN = ( 0, 0, 0, 0, 0, 0 )
#local Sta_I_APL =
(vector(15),vector(15),vector(15),vector(15),vector(15),vector(15) )
#local Sta_I_UN =
(vector(2005),vector(2012),vector(2031),vector(2042),vector(2051),vector(2091))

.
.

The definition file above will create NOD:B objects for base systems and PC-NET nodes.
After this, the STAn:B objects are created for each station object created to the PC-NET
nodes. This configuration should match with the configurations entered with System
Configuration Tool.

When a hot stand-by switch, that is, “take-over” occurs during run-time, the main
application changes to HOT state in the adjacent base system. In this situation, a procedure
SHADMAPNET is executed and PC-NET nodes are informed that the application is
running in another base system node. The used attribute is NET node attribute SY.

4.4. Configuring System Self Supervision

System Self Supervision (SSS) provides information about the status of the software and
hardware components of the MicroSCADA Pro system. This information appears as
supervision events in the Event and Alarm Lists. Typically, the dedicated System Self
Supervision process display should become constructed to show the status information
in the graphical view by using the supervision symbols with the status symbol appearance
and color semantics. Supervision symbols are dynamically updated, and thus always
reflect the real status of the supervised system. Supervision symbols also provide an
access point for launching the appropriate Supervision Control Dialog for monitoring
more detailed information about the selected object, or being used for controlling opera-
tions, such as performing manual switch-over in the redundant system. Standard
authority handling mechanisms are applied to supervision controlling operations.

For information on the System Self Supervision functionality from the operator's point
of view, see SYS 600 Operation Manual. For information on the configuration steps
from the project engineer's point of view, see SYS 600 Application Design manual. SYS
600 Application Design manual also includes information on how to adjust the System
Self Supervision functionality to the project-specific needs.

112
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

While introducing the supervision logic in application, follow the design considerations
given below:

1. Keep the supervision logic for each component as simple as possible. Introducing
more application objects into the re-processing chain of the same supervision event
means that there will be delays and the granularity of the operation will be split to
several places.
2. Represent the status information in binary way - one value representing the good
status, and another value representing the bad status. In the SYS 600 process database,
use process objects of type Binary Input for this. Use naming convention for the
supervision process objects, as it is easier to recognize them among the other
application process objects.
3. When detailed information is needed for certain system component, include detailed
pictures or displays providing the detailed information on request.
4. Use Windows operating system events by using OS_EVENT predefined event
channel and re-route the information into the process objects.
5. If system contains the devices capable for sending the SNMP messages in SYS 600
network, use SNMP-OPC gateway solution. It helps you to map the supervision
information into process objects by using the subscription of related OPC items
from the SNMP-OPC Server namespace.
6. When engineering system supervision picture, try to re-use the symbols found from
the Palette of SYS 600 Display Builder. Include the color semantics representing
the status information either beside the symbol or inside the symbol, when feasible.

4.5. Configuring communication gateway

Before the gateway engineering can start, the application has to be prepared for the
gateway functionality. This is done in the Signal X-Reference Tool as shown in Fig-
ure 4.5-1. Once the application is prepared, it should be restarted, as shown in Figure 4.5-
2. After restarting of the application, COM 500I creates all the necessary application
objects, such as event and time channels, and command procedures are created automat-
ically, also the directory\sc\apl\ <name> \com500, that is used for storing cross-reference
files and parameter files.

A070466

Figure 4.5-1 Prepare COM 500I application

113
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

A070467

Figure 4.5-2 Application prepared successfully

4.5.1. SYS_BASCON.COM modifications

Command procedures of COM 500i use parallel queues and COM 500i applications
must be introduced in SYS_BASCON.COM.
#local COM500 = vector(TRUE) ;TRUE = COM500i application,
;FALSE = not COM500i application
…
#if COM500(j) #then - ;COM500i Application
Apl_Permanent = merge_attributes(Apl_Permanent, -
list(PQ = 16,- ;Number of
parallel queues
QD = (1,1,0,0,0,0,1,1,1,1,1,1,1,1,1,1))) ;Parallel
queue

;dedication

4.5.2. Gateway license

The gateway functionality can be used, if the value in the gateway field is non zero. The
value also tells, how many NCC lines can be configured in the Signal X-Reference Tool.

Figure 4.5.2-1 Gateway license

4.6. Configuring peripheral equipment

The following devices have connection from MicroSCADA (are defined in
SYS_BASCON.COM):

• Printers
• I/O cards (Adaptech 1760, Nudaq 7250 and 7256)
• Meinberg clock cards

114
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

4.6.1. Configuring printers

To connect a printer directly to a base system computer, follow the instructions given
below:

1. Connect the printer to a parallel or serial port. Printers connected to the parallel port
of a base system computer can be placed at a maximum 3 meters from the base
system computer. Serial lines allow the connection lines to be up to 15 meters without
modem.
2. Configure the printer to the operating system as described in the Windows manuals.
Define the printer as “shared” if it is going to be used by several base systems or
other Windows computers on the LAN.
3. Select the connection mode on the printer.
• Select parallel mode if the printer is connected to the parallel port.
• Select serial mode if it is connected to a serial port.
4. Configure the printer in the base system as a PRIn:B object. If the printer is used
by several base systems, or by programs other than MicroSCADA Pro on the same
or other computers, set the printer's OJ attribute to 1.

Printers, that is used by several base systems, should be defined in all base systems, both
regarding the operating system configuration and the MicroSCADA Pro configuration.

4.6.1.1. LAN connection

Printers connected to a base system computer or LAN should be configured in all base
systems that will use the printers.

4.6.1.2. NET connection

A printer connected to a PC-NET communication unit can be used by all base systems
connected to the same network. The printer should be defined both in the base systems,
which uses it and in the PC-NET unit to which it is directly connected, as shown in
Figure 4.6.1.2-1 . It is assumed that the PC-NET unit has been defined to the base system
as a NODn:B object.

Include the following definitions in each base system which will use the printer:

1. Create a PRIn:B base system object with at least the following attributes:

TT “LOCAL”
ND The node number of the NET unit to which the
printer is directly connected
TN The device number of the printer in the NET
unit to which it is directly connected

115
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

DT "COLOR", "NORMAL", or "TRANSPARENT"

Select "NORMAL", if the printer will be used
exclusively for black-and-white character-based
printout. Select "COLOR" for all other types of
picture based printout. Even if the printout will
be black-and-white, "COLOR" is preferable as
this mode provides a more picture resembling
printout by exchanging graphical characters to
printer specific characters. Select "TRANSPAR-
ENT", if the printout will be SCIL defined.
DC "NET"

In addition, optional features are defined by the following attributes:

LP Lines per page

QM Queue length maximum
OD Output destination: "PRINTER", "LOG" (disk
files) or "BOTH”
LD, LL, LF Printer log attributes, specify the management
of log files The attributes are meaningful, if OD
= "LOG" or "BOTH”

For more information on the attributes of the PRI object, see SYS 600 System Objects.

2. If needed, map the printer for an application with the APLn:BPR attribute. The printer
mapping is required only if you want to use a logical printer number which is not the
same as the printer object number.

Only the printers mapped with the logical printer numbers 1

... 15 can be used as alarm and event printers; printer 15 is
reserved for event lists.

Include the following definitions in the NET unit to which the printer is directly connec-
ted:

116
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

A070475

Figure 4.6.1.2-1 Configuration of a printer connected to NET unit

1. Select a line for the printer and define the line with the ASCII protocol:

PO 4
IU 1
LT 0
MS, MI System message handling, see Chapter 17.
PS Buffer pool sizes, see
BR Baud rate (recommended value 2400)
PY 0

117
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

RD 8
SB 1
TD 8
OS Output synchronization, see SYS 600 System
Objects

2. Define a printer (a PRI object) on the selected printer line with the attributes:

LI The number of the selected line

IU 1
MI, MS System message handling
AL, AS 0 (the printer reservation is handled automatic-
ally by the base system
PT Printer type 1 = character-based, black-and-
white 2 = "transparent" 3 = pixel based, black-
and-white 5 = character-based, black-and-white,
graphical characters replaced by printer charac-
ters 6 = Facit 4544 7 = pixel-based, color

For more information on the attributes of the PRI object, see SYS 600 System Objects.

The three attributes mentioned can be found inSYS 600 System Objects.

When a base system is started, its default application (the application created first in
SYS_BASCON.COM) sends a message to the printers (form feed). Therefore, make
sure that these applications are defined in the NETs.

4.6.2. Configuring I/O adapter cards

I/O signals can be used for external alarm output and input indications.

The supported I/O cards are ADLink NuDaQ PCI-7250, PCI-7256 or Advantech PCI-
1760 Alarm panel, supplied by ABB Distribution Automation, Finland.

Alarm panel includes seven led indicators, one for each alarm class, watchdog alarm
indicator, buzzer for audio alarm (can be switched off by using jumper), quit button for
alarm leds and connector for external alarm reissuing. On input side there are two parallel
connections, which enable two systems to drive one alarm panel.

MicroSCADA supports two different I/O cards. Both the cards require own connection
cable for alarm panel. Card end of cable is D37 (male) and the other end is D25 (male).

To run external horns, robot phones or other equipment, alarm panel includes a relay
output. Functionality is parallel to alarm panel indicators. Alarm outputs (excluding

118
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

watchdog) are available also without alarm panel. Driver programs are from card manu-
facturers. SYS object AA is used in MicroSCADA configuration.

The signals available from I/O cards and cable wiring for ABB Alarm Unit are shown
in the table below:
Table 4.6.2-1 Signals from I/O cards
Connector (D25 female) Relay outputs ACx = Alarm Class x

1 AC1
2 AC1
3 AC2
4 AC2
5 AC3
6 AC3
7 AC4
8 AC4
9 AC5
10 AC5
11 AC6
12 AC6
13 AC7
14 AC7
15 ALARM QUIT (INPUT - )
16 ALARM QUIT (INPUT + )
17 WATCHDOG
18 WATCHDOG
19
20
21
22
23
24
25

119
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

A070714

Figure 4.6.2-1 Cable diagram for Nudaq

For more information about the Advantech PCI-1760 and ADLink PCI-7250 and PCI7256
I/O driver installation and configuration, refer to the respective card manufacturer docu-
mentation. The Windows drivers for PCI cards are delivered with the cards.

The driver versions supported by MicroSCADA Pro are:

• Version 2.0 of the ADLink’s PCI-7250 I/O card driver for Windows.
• Version 1.10 of the Advantech’s PCI-1760 I/O card driver for Windows.

The supported versions of the drivers are available in the following websites:

• ADLink website: http://www.adlink.com.tw/home.htm

• Advantech website: http://www.advantech.com/

120
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

4.7. Configuring time handling

In general, the time synchronization of the SYS 600 system and connected IEDs is
necessary in order to interpret correctly any time-stamped information provided by the
system. The time-stamped information can be, for example, the event information from
the IEDs.

The SYS 600 system uses the internal clock of the computer as the source of time.
Depending on the configuration and the system structure, this clock may be synchronized
from an external source such as GPS, radio clock or another SYS 600 system. The GPS
clock reference device is connected through a SLCM card via a LON line or using an
external application. When the SYS 600 system is operating as a communication gateway,
the synchronization is often received from the network control center through the used
communication line. If IEC 61850 communication server is used in MicroSCADA PC,
SNTP time synchronization can be used.

The same internal clock is used, when the real IEDs connected to the SYS 600 system
are synchronized through the communication lines in process communication units. In
most of the communication protocols there is a predefined method to synchronize the
IEDS. For more information about the synchronizing methods, see the protocol specific
manuals. When SYS 600 is used to synchronize the IEDS, the synchronization command
is usually initiated cyclically from the application running in the base system. The related
station object attribute is SY for many protocols. In some protocols, there is a possibility
for the IEDS to request a time synchronization from the master.

The process communication units running in the same computer use the same system
clock, which means, there is no need to make separate synchronization for the unit. This
is different from the DCP-NET units used with the older SYS base system versions,
where the units had a separate clock in the used hardware.

When operating as a communication gateway, the network control center may operate
in a different time zone. The corresponding compensation attribute is TZ which exists
both in SYS:B object and NET:S object (only for process communication unit PC-NET).

4.7.1. Configuring time synchronization

The time synchronization characteristics usually vary from one system to another and
are strongly dependent on customer and/or IEDS requirements. The communication
protocol used, also has an effect. For example, with SPA-protocol the time synchronization
command is sent every second. With some other protocol, the interval of the time syn-
chronization may be hours.

The following steps should be considered when the time synchronization concept for a
SYS 600 system is planned:

1. Find out the system requirements.

2. Resolve the clock reference for the planned system.

121
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

3. Resolve IEDS requirements with the used communication protocol.

4. Define the synchronization intervals for IEDs or IEDS groups.
5. Define the time synchronization details of the used protocol.

In step 2, it is defined if the clock of the SYS 600 computer is synchronized from an
external source. This source could be a network control center or a radio clock device
connected to a communication line in PC-NET, an external application using SNTP
server and/or GPS device, a SLCM-card connected to LON star coupler and so on.

If the source of the time is connected to communication line of the PC-NET, some con-
figurations tasks may be required. For IEC60870-5-101/104 and DNP3.0 protocols, see
the corresponding slave protocol manuals, station attribute TC. For LON protocol, see
SYS 600 System Objects. The time zone compensation is done with attribute SYS:BTZ.

If the source of the time is an external application or a special device, see the correspond-
ing manuals for more information.

In step 3, the requirements of the used IEDs are defined. These requirements may define
the minimum frequency of the incoming time synchronization or it may require that the
synchronization should be preceded by a delay measurement. The IEDS may also define
if it accepts the time only with or without date or only as a broadcast message. It is also
possible to synchronize the device from an external time source and it need not be done
from SYS 600 at all.

Steps 4 and 5 require SYS 600 application programming. With protocols implemented
to process communication unit PC-NET, a common practice is to define a time channel
or a set of time channels which are executed with a defined interval. A command proced-
ure which actually initiates the synchronization is then connected to the time channel.

Example for DNP3.0 master protocol:

#LOOP_WITH I=20..25
#IF STA’I’:SIU==1 AND STA’I’:SOS==0 #THEN #BLOCK
#SET STA’I’:SSY=(1,0) ; direct, no time delay measurement
#PAUSE 10
#BLOCK_END
#LOOP_END

If this procedure is attached to a time channel, which is executed with 1 hour interval,
the IEDs related to STA20..STA25 are synchronized once every hour. The same station
object attribute SY is used for time synchronization in most protocols implemented to
PC-NET. For more details, see the protocol specific manuals and System Objects manual.

4.7.1.1. Configuring external clocks

DCF77 radio clock from Meinberg

The board PCI511 has been designed for the reception of the DCF77 signal, the transfer
of the time information to a computer with PCI (PCI-X) bus interface. Install the card

122
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

to a free PCI bus card place. After switching on, it will ask to locate the place of the
driver software.

The drivers package contains a monitor program (for more information, see Figure 4.7.1.1-
1), which allows the user to check the status of the device. It is also useful to modify
parameter configuration.

A070709

Figure 4.7.1.1-1 Configuring Meinberg radio clock

4.7.2. Configuring time zone and daylight saving

To adjust computer clock and MicroSCADA applications to daylight saving time, follow
the instructions given below:

1. Open Control Panel > Date and Time.

2. Click the Time Zone tab to change your zone.
• To perform the above action, click the drop-down arrow, and then select your
current zone.
3. Select Automatically adjust clock for daylight saving changes.
4. Open Monitor Pro > Tools > Options.
5. Click Daylight Settings > Automatically adjust applications for daylight saving
changes.

123
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

4.7.3. Time zone and daylight saving history

The base system maintains the history of time zone and daylight saving time rules obeyed
in the site. The history is found in file SYS_TIME.PAR located in folder
\SC\SYS\ACTIVE\SYS_.

The history is used for two purposes:

• To display old time tags correctly

The site may have been moved from a time zone to another, or daylight saving time
may have been applied differently in the past. As the base system stores the time
tags in UTC time, the history is needed to correctly convert the tags to the local time
of the moment of event.
• To time future actions correctly

The base system transfers the current time zone and daylight saving information from
the operating system at each system startup and maintains the history automatically.
However, there are a few cases, where you might want to edit the history explicitly:

• Time zone and/or daylight saving time settings are changed and it is not acceptable
to shut down and restart the system for this reason.
• Prior to SYS 500 revision 8.4.4, the time tags were stored in local time. If a revision
8.4.3 application or older is upgraded and the time zone and/or daylight saving time
settings have been changed during the age of the application, the old settings should
be copied to the base system to display old time tags correctly.
• If it is known that time zone and/or daylight saving time settings are to be changed
in the future, it is useful to transfer the new settings to the base system in advance.
Then, the base system is able to correctly time the once-only time channels scheduled
after the coming change of settings. In addition, other local/UTC time conversions
of future time tags are done correctly.

The explicit editing of SYS_TIME.PAR is done with SCIL function

TIME_ZONE_RULES, see SYS 600 Programming Language SCIL.

As there are some complications of local/UTC time handling,

it is recommended that engineering of a new application is
done in a PC that uses the time zone and daylight saving time
settings of the target site.

4.7.4. Configuring representation of dates

There are two places to configure representation of time and date in Monitor Pro:

• TF-attribute
With TF-attribute the following conventions are available:
yy-mm-dd hh:mm:ss, when TF=0

124
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

dd-mm-yy hh:mm:ss, when TF= 1

mm-dd-yy hh:mm:ss, when TF= 2
The default value for time format can be configured in SYS_BASCON.COM, where
node for base system is created.
Extract from SYS_BASCON.COM
#local Sys_Modify = list(-
-; Communication Attributes
ER = 0,- ;Enable Routing 0=disabled, 1=enabled

TI = 10,- ;Timeout Length

-; Time Handling Attributes
TM = "SYS",- ;Time Master, SYS or APL
TR = "LOCAL",- ;Time Reference, LOCAL or UTC
TF = 0,- ;Time Format
-; 0 = yy-mm-dd hh:mm:ss
-; 1 = dd-mm-yy hh:mm:ss
-; 2 = mm-dd-yy hh:mm:ss

Like Alarm list and Event list, Monitor Pro applications follow
time format defined by TF.

• Initialization file FRAMEWINDOW.INI

FRAMEWINDOW.INI is a user specific file and it is located in directory \sc\apl\'
apl name'\PAR\'user name'. The representation order of time and date can be con-
figured in DAYFORMAT section of the above mentioned file. The configuration
applies for the Monitor Pro status bar. To learn more about this configuration, see
the example given below:
[DAYFORMAT]
FreeDateTimeField=%Y-%m-%d %H:%M:%S

The default represention style in status bar follows the TF-attribute setting. If
DAYFORMAT is defined it will be used.
A list of all possible options for configuring DAYFORMAT is given below:
• Year
%y, Year without century
%Y, Year with century
• Month
%b, Abbreviated month name
%B, Full month name
%m, Month as number (01 – 12)
• Week
%W, Week of year as decimal number, with Monday as first day of week (00
– 53)
%U, Week of year as decimal number, with Sunday as first day of week (00 –
53)
• Day
%d, Day of month as number (01 – 31)
%j, Day of year as number (001 – 366)

125
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

%w, Day of week as number (0 – 6; Sunday is 0)

%a, Abbreviated weekday name
%A, Full weekday name
• Hour
%H, Hour in 24-hour format (00 – 23)
%I, Hour in 12-hour format (01 – 12)
%p, Current locale's A.M./P.M. indicator for 12-hour clock
• Minute
%M, Minute as number (00 – 59)
• Second
%S, Second as number (00 – 59)
• Misc
%c, Date and time representation appropriate for locale
%x, Date representation for current locale
%X, Time representation for current locale
%z, %Z, Either the time-zone name or time zone abbreviation, depending on
registry settings; no characters if time zone is unknown

4.8. Configuring networks

Each NET unit, which is connected to a base system via one or more than one units,
should be defined to the base system as a node (NODn:B objects):

1. Create a NODn:B base system object corresponding to the indirectly connected

communication unit. The NOD object number ('n') should be the same as the node
number of the communication unit. The NOD object is given the following attribute
values:
LI = Link number (= LIN object number). This is the link to the nearest communic-
ation unit
SA = Station address of the indirectly connected communication units
Even if there is no communication between the base system and the indirectly con-
nected NET, the node definition is necessary for the system diagnostics, online
configuration and system maintenance.
Correspondingly, each base system connected to a NET unit indirectly via other
units should be defined to the NET unit as a node.
2. Define an "External node" (NET object) on the line to the nearest communication
unit:
Device type = NOD
Device number = The node number of the indirectly connected base system
LI, Line number = The line to the nearest communication unit in the series
SA = Station address of the indirectly connected base system
3. Define an application for each application in the indirectly connected base system.

126
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

Example

Figure 4.8-1 shows an example of a network of two base systems and a Front-end

system containing two communication units. Application 1 communicate to process
true Front-end system, and APL1 and APL5 (in Base system2) communicate with
each other.

The example includes only the definitions which are of importance for this particular
configuration.

A070712

Figure 4.8-1 Network of two base systems and a Front-end system containing two

communication units

Configuring base system 1

#local LAN_Link = 1 ;LAN link number

.
.

;
;Other Base System Nodes
;
#local NOD_Numbers = vector(10, 11),-
NOD_Names = vector("10.10.10.10", "10.10.10.11"),-
NOD_Addresses = vector(210, 211)

127
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

;Gateway Nodes
;
#local GW_NOD_Numbers = vector(1,2),-
GW_NOD_Addresses = vector(201,202)
.
.

;
;External Applications
;
#local Ext_Apl_Numbers = vector(5),- ;for example vector(15,16),-
Ext_Apl_NA = vector("APL5"),-
Ext_Apl_ND = vector(11),-
Ext_Apl_SN = vector(0),- ;Shadowing partner application
Ext_Apl_TN = vector(5),-
Ext_Apl_EM = 5000,- ;Maximum length of mirroring queue
Ext_APl_EP = "KEEP" ;Event queue overflow policy, "DISCARD"
or "KEEP"

Configuring Base system 2

#local LAN_Link = 1 ;LAN link number

.
.
;
;Other Base System Nodes
;
#local NOD_Numbers = vector(9),-
NOD_Names = vector("10.10.10.9"),-
NOD_Addresses = vector(209)

;
;Gateway Nodes
;
#local GW_NOD_Numbers = vector(),-
GW_NOD_Addresses = vector()

.
.
;
;External Applications
;
#local Ext_Apl_Numbers = vector(1),- ;for example vector(15,16),-
Ext_Apl_NA = vector("APL1"),-
Ext_Apl_ND = vector(9),-
Ext_Apl_SN = vector(0),- ;Shadowing partner application
Ext_Apl_TN = vector(1),-
Ext_Apl_EM = 5000,- ;Maximum length of mirroring queue
Ext_APl_EP = "KEEP" ;Event queue overflow policy, "DISCARD"
or "KEEP"

Configuration of Front-end system

128
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

#local LAN_Link = 1 ;LAN link number

.
.
;
;Other Base System Nodes
;
#local NOD_Numbers = vector(9),-
NOD_Names = vector("10.10.10.9"),-
NOD_Addresses = vector(209)

;
;Gateway Nodes
;
#local GW_NOD_Numbers = vector(),-
GW_NOD_Addresses = vector()

.
.
;
;External Applications
;
#local Ext_Apl_Numbers = vector(1),- ;for example vector(15,16),-
Ext_Apl_NA = vector("APL1"),-
Ext_Apl_ND = vector(9),-
Ext_Apl_SN = vector(0),- ;Shadowing partner application
Ext_Apl_TN = vector(1),-
Ext_Apl_EM = 5000,- ;Maximum length of mirroring queue
Ext_APl_EP = "KEEP" ;Event queue overflow policy, "DISCARD"
or "KEEP"

4.8.1. Configuring Local Area Networks (LAN)

To connect a base system to a LAN, create a LINn:B object with the following attributes
(for more information, see SYS 600 System Objects):

LT = "LAN"

TR = "TCPIP"

All workplaces and base systems can use the same LIN object, that is only one LIN
object definition is required.

LAN nodes

In the LAN network, each connected base system and workplace has a LAN node name
or number. The LAN node names are used in the SYS 600 configuration to achieve
communication between base systems, between base systems and LAN connected devices.
Use static IP addressing. This indicates that the computer is manually configured to use
a specific IP address. Using DHCP for IP assignment is not verified. To get an idea about
Base System Configuration, see Figure 4.8.1-1:

129
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

A070713

Figure 4.8.1-1 Example of a SYS 600 configuration for a LAN

#local LAN_Link = 1 ;LAN link number

.
.
;
;Other Base System Nodes
;
#local NOD_Numbers = vector(7,30),-
NOD_Names = vector("TROIJA", "10.58.125.123"),-
NOD_Addresses = vector(207,230)

4.8.2. Communicating between applications

The object data in one application can be read and written from another one by means
of the object notations. This communication is called also as APL - APL communication.

Communication between applications in the same base system, that is between two local
applications, is achieved simply by application mapping (the APLn:BAP attribute).

Communication between applications in separate base systems requires that the base
systems are physically connected to each other, either through LAN or through direct
serial lines. The configuration and communication principles are the same, independently
of the route between the base systems. The communicating base systems are identified
to each other by node numbers and station addresses and the link to the nearest node.
The route through the network does not need to be defined.

4.8.2.1. Local applications

Suppose that application 'a' needs to read and write data in application 'b' in the same
base system, as shown in Figure 4.8.2.1-1. Application 'b' should then be "introduced

130
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

to" application 'a' by means of application mapping (For more information, see SYS 600
System Objects):
#SET APLa:BAPi = b

where

'i' The logical application number under which application 'a' recognizes application 'b'

To avoid complexity, it is recommended to let the logical

number be the same as the object number of the application,
that is 'i' = 'b'. For example, setting #SET APL1:BAP2 == 2
means that APL2 is recognized to APL1 by the logical
application number 2. In application 1 it is possible to read
object data in application 2, for example with the notation:
OBJ:2POV1.

A051611

Figure 4.8.2.1-1 Illustration of the data communication between applications in the same base

system

131
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

4.8.2.2. Applications in separate base systems

Suppose that application 'a' in base system 1 needs to read and write data in application
'b' in base system 2. Then the following configurations are required in base system 1:

1. Create a LINn:B object for the link to the base system 2 (if it does not already exist).

2. Create a NODn:B object representing base system 2, where 'n' is the node number of
base system 2.

The NODn:B object should be assigned at least the following attributes:

LI The number of the link to base system 2 (the

LINn:B object number, see above)
SA Station address of base system 2

In addition, if LAN is used:

NN LAN node name of base system 2 (see “LAN

nodes” in 4.8.1, Configuring Local Area Net-
works (LAN)).

3. Create an external application, an APLn:B object, referring to application 'b' in base

system 2. For clarity, use the same object number ('n') as the application object number
in base system 2 (although this is not a requirement), that is create APLb:B. Assign the
APLb:B object the following attributes:

TT "EXTERNAL"
ND Node number of base system 2
TN Application object number in base system 2 ('b')

4. Map the external application in base system 1 to the communicating application,

application ‘a’, by setting APLa:BAPi = b, where 'i' is the logical application number
under which application ‘a’ recognizes application ‘b’. If there are no obstacles, let the
logical number be the same as the object number of the application (that is 'i' = 'b').

132
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

A051612

Figure 4.8.2.2-1  Illustration of the configuration and data communication between two

applications situated in separate base systems

LAN link configuration

Refer to Figure 4.8.2.2-1.
;LAN link:
#CREATE LIN1:B=LIST(-
LT="LAN",-
TR="TCPIP")
;Node for Basesystem 2:
#CREATE NOD10:B=LIST(-
LI=1,-
SA=210,-
NN="90.0.1.124")
;Application 1:
#CREATE APL1:B=LIST(-
AP3=3)
;Application 3:
#CREATE APL3:B=LIST(-
TT="EXTERNAL",-
ND=10,-
TN=3)

133
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

4.9. Configuring redundancy

4.9.1. Hot stand-by base systems

In a hot stand-by base system, two base system computers are interconnected via a LAN
in a redundant relationship, where one or both base systems are prepared for fast takeover
at system break-down in the other base system. An application in one base system
operates as the hot application, while an identical application in the other base system
is a stand-by application. The stand-by application is maintained by a continuous shad-
owing (copying) of data from the hot application.

When a fault occurs in the primary base system (the base system containing the hot
application), the shadowing application in the stand-by base system is started and takes
over all the operational functions. After recovery and restart of the former primary base
system, it can either be used as stand-by base system, whereby the former stand-by base
system is the primary base system, or the base systems can be returned to their original
tasks.

During normal operation, the two base systems can function independently, each running
one or more applications, for example, electrical energy distribution and district heating.
Alternatively, one base system can be reserved exclusively for stand-by duty. Both base
systems can contain several applications connected with an application in the other base
system in a shadowing relationship. In the following description, it is assumed that the
base systems contain only one shadowing application pair, but the same principles apply
to systems with several shadowing applications.

4.9.1.1. Functional description

During normal operation, the running application in the primary base system sends
continuously shadowing data to an identical application in the stand-by base system.
Shadowing means that the following data is copied from the running application to the
stand-by application:

• All changes of files, including deletions, on disk under the application subdirectories
(APL_, PICT, FORM, etc.). The files in the application root directory are not copied.
• Changes of application data (process and report data) stored in RAM. Other changes,
such as changes of cache memories, monitor states, printer spool and execution
queues, are not copied.
• Last transaction number, that is, the number of the last RP-570 or SPACOM event
message transferred from PC-NET.

Neither the SYS_ folder nor any other folder outside the
application directory is shadowed. Therefore, if customizations
are done in these folders, they are lost at the takeover.

134
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

File management done outside the SYS 600 program is not

shadowed. Therefore, always use SYS 600 tools instead of
operating system utilities for file management (copy, delete,
rename, and so on).

An update of an object constitutes a transaction. A transaction consists of atoms, which

are the smallest quantity of data modified in RAM. The primary base system collects
the transactions in a buffer. The data in the buffer is transmitted to the standby system
as long messages (64 kB). A transmission is performed when the oldest transaction in
the buffer has been there for a preselected time (the Shadowing Flush Time (SF) attribute,
default = 100 ms), or when the buffer is full. This means that data is transmitted more
often in situations when the databases are updated frequently.

Besides the shadowing data messages, the hot application sends cyclically diagnostic
commands and time synchronization commands to the stand-by application. If it does
not receive an acknowledgement to the messages, the connection to the stand-by
application is regarded as broken, and the shadowing halts until the connection is re-
established.

The watchdog application in the stand-by base system monitors the diagnostic commands
and messages from the hot application. It starts an event channel if message or diagnostic
commands are not received within a specified time. The event channel starts a command
procedure, which examines the situation and performs a switch-over if needed.

Switch-over means that the former stand-by application is switched to hot application.
When the stand-by application is set to HOT, an event channel APL_INIT_H is started
(instead of APL_INIT_1 and 2). The event channel may be used, for example, for
reconfigurations and updating. Apart from an ordinary application start-up, no process
data is copied from disk to RAM. The watchdog application in the new primary base
system tries to connect to the former hot application (which is now regarded as stand-by
application) cyclically with a specified time interval. At switch-over, the workstation
programs (Monitor Pro and Classic Monitor) must be restarted by application programs,
or manually.

When the former primary computer is restarted after recovery, all files under the stand-
by application subdirectories are automatically deleted and the application files are copied
from the hot application (file dump). Likewise, all application data of the hot application
stored in RAM is copied to the stand-by application (RAM dump). While the RAM data
is copied, which may take some seconds depending on the application, the running
application is out of operation. A new switch-over is obtained by a simulated error, for
example, by setting the primary main application to cold.

4.9.1.2. Configuring hot stand-by systems

Minimum configuration requirements are listed below:

135
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

• Two complete base systems connected to a LAN, each including at least two
applications: one main application, which is a part in the hot stand-by relation, and
one watchdog application which is dedicated for monitoring the main application
and performing a switch over when needed.
• A local area network (LAN), TCP/IP.
• A standard watchdog application software package in each base system. The
watchdog software package contains command procedures and data objects for
monitoring the operation and reconfiguring at switchover.

Options:
• Additional applications in both base systems
• Operator workplaces

The following procedure describes the steps to be taken to configure a hot stand-by base
system:
1. Install the MicroSCADA Pro Technology software for both base systems as described
in the Installation and Commissioning Manual.
2. Edit SYS_BASCON$COM template and rename it to SYS_BASCON.COM for
both base systems.
3. Start base system that should have the hot application.
4. Install standard watchdog application software.
5. Define external watchdog application and start the main application.
6. Start stand-by base system.
7. Install standard watchdog application software in the stand-by base system.
8. Define external watchdog application software in the stand-by base system.
9. Edit command procedures in the watchdog applications for both base systems.

4.9.1.3. SYS_BASCON.COM in hot stand-by systems

The MicroSCADA Pro software delivery includes a version of SYS_BASCON.COM

template, SYS_BASCON$COM which contains all the necessary configuration definitions
for a hot stand-by, too. The file is listed in 4.1.2.1, Base system objects.

To turn on the hot stand-by functionality in SYS_BASCON.COM, change the value of

the variable Hot_Standby to TRUE in the beginning of the file.
#local Hot_Standby = TRUE ;Hot Stand-by enabled/disabled

Except for the node numbers, the SYS_BASCON.COM files of both base systems can
be identical.
#local This_Node_is = BS_Nodes(1) ;This system 1 or 2 (Always 1 for single
system)

The standard base system configuration defines that both main applications are COLD
when the base systems are started, only the watchdog applications are running.

136
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

The principles for the initial configuration of a hot stand-by base system in
SYS_BASCON.COM are shown in Figure 4.9.1.3-1.

A051616

Figure 4.9.1.3-1 Example of two redundant base systems

The example in Table 4.9.1.3-1 illustrates only the attributes and parameters that are
significant for hot stand-by. For information on the shadowing attributes and other
application attributes, see SYS600 System Objects manual.
Table 4.9.1.3-1 Start-up configurations for two redundant base systems
Configuration of base system 1: Configuration of base system 2:
Base system: SH=1 Base system: SH=1
Application 1 (internal): Application 1 (internal):
• NA = "TUTOR" • NA = "TUTOR"
• AS = "COLD" • AS = "COLD"
• SN = 3 • SN = 3
• SR = 1 • SR = 1
• SI = 100 • SI = 100
• SW = 2 • SW = 2
• SY = 0 • SY = 0
• AP = (1,2,3,4) • AP = (1,2,3,4)
Application 2 (internal, default application): Application 2 (internal, default application):
• NA = "WD" • NA = "WD"
• AS = "HOT" • AS = "HOT"
Application 3 (external): Application 3 (external):
• NA = "ADJ_MAIN" • NA = "ADJ_MAIN"
• TT = "EXTERNAL • TT = "EXTERNAL"
• ND = 10 • ND = 9
• TN = 1 • TN = 1

137
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

Application 4 (external): Application 4 (external):

• NA = "ADJ_WD" • NA = "ADJ_WD"
• TT = "EXTERNAL" • TT = "EXTERNAL"
• ND = 10 • ND = 9
• TN = 2 • TN = 2

4.9.1.4. Watchdog application

The watchdog application software package handles the following procedures for all hot
stand-by applications within a base system:

• When the base system is started, it checks which main application was operating
last and sets the application state (AS) to HOT and the shadowing state (SS) to
HOT_SEND.
• During the operation, it monitors the messages sent from the hot application. If no
messages are received in a specified time defined by the Shadowing Receive Timeout
(SR) attribute a switchover is started and the stand-by application is set to HOT and
shadowing is started (SS = HOT_SEND) when the connection is re-established.
• If the hot system does not get acknowledgments from the stand-by system, it regards
the connection as broken, and the shadowing stops (SS = NONE). The watchdog
application then checks the connection by sending commands cyclically (with a few
minutes interval) to the stand-by system, and starts shadowing (SS = HOT_SEND)
when the connection is re-established.

Installing Watchdog application

To install the watchdog application package, follow the instructions given below:

1. Enter the Base System Object Navigator on the System Configuration page of the
Tool Manager.
2. Select Base Objects (SYS) from the object tree.
• Installed Package
Version: The name and revision date of a previously installed package.
Status: The status of the installed package, running or not running.
• Disk Package
Version: The hot stand-by software package installed on a disk.
Status: The status of the disk package (OK, DISK PACKAGE NOT FOUND
or FILE READ ERROR (SHAD_VERS.CIN): error number).
3. Click Install to install the watchdog software package. The installation creates a set
of command procedures, data objects and time channels. When the installation is
complete, the name and revision date of the package appears in the Installed Package
Version field.

138
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

Editing the command procedures of the watchdog application

The watchdog application package contains a set of command procedures. The following
command procedures can be freely customized, whereas the others should not be edited.

While editing the command procedures, the existing part of

the contents should be left as they are and the modifications
are added to the end of the command procedure.

SHADUSR The generation of alarms and events in the

situations when:

• Hot stand-by transmission starts

• File and RAM dump is ready
• Connection is lost to the receiver (in the
stand-by system)
• Takeover starts
• Change of state occurs in the partner
application
SHADMAPMON The shifting of classic monitors at takeover, for
example, mapping monitors for the main
application, or opening application windows
using the SCIL function OPS_CALL and the
mons.exe command. For more information on
how to open application windows, see SYS 600
Installation and Administration Manual. When
a monitor is mapped to an application, an event
channel MON_EVENT is activated. This can
also be used in registering the SD attribute of
an X terminal, for example, in the Instruction
(IN) attribute of a command procedure. At
switchover, the SD attribute can be used for
opening a window in the same terminal.
SHADMAPNET Reconfiguration of the communication units at
takeover. This is currently not the primary
method to use for the reconfiguration.

In case the PC-NET process communication

units are distributed, the redefinition of the APL
objects of the PC-NET units should be done
using the SY attribute of the PC-NET node. This
can be done by editing the SHADMAPNET
procedure or from a separate procedure connec-
ted to the APL_INIT_H event channel of the
main application.

139
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

SHADGOHOT Specifies whether the main application is

allowed to be set HOT when a lost connection
has been discovered. The command procedure
can contain a check of the error, for example,
if the communication disturbance is due to a
communication fault on the LAN connection to
the stand-by system. Then no switchover should
be performed. By default, the application is set
to HOT.
SHADREMHOT Specifies whether the main application is
allowed to remain HOT when also the standby
application is HOT. Such situation can occur at
a LAN break. By default, the application remains
HOT.

4.9.1.5. Shadowing

To define the external watchdog application and enable hot stand-by, follow the
instructions given below:

1. Click Shadowing Applications. A list of HSB applications is shown in the dialog.

2. Click the row of the local main application that you want to modify and click the
Edit button.
3. Check the HSB check-box to set the HSB On.
4. Select the external watchdog application in the drop down list and click OK (or
Apply and Cancel).
5. Repeat steps 2-4 for each main application.

File dumps and shadowing will start after the HSB has been enabled for the main
applications in both base systems.

A takeover should not be done before the file dump is com-

pleted.

The file dump of an application is completed when the shadowing state attribute SP =
HOT_SD.

4.9.2. Hot stand-by with OPC client and servers

The principles of the HSB concept in systems including OPC client and servers connected
to IEC 61850 process devices has been described in the SYS 600 IEC 61850 System
Design manual. The following sections describe the recommended configuration
sequences for External OPC Data Access Client start-up and how the related stations
should become activated for the communication during the switch over.

140
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

4.9.2.1. Starting an External OPC Data Access Client

External OPC DA Client should be started from the watchdog (WD) application. The
recommendation for the HSB systems is that all communication components, for example,
External OPC DA Client, PC-NET related protocols or any communication protocol
based on the Communication Protocol Interface (CPI) should be started in this way. In
practice, this startup logic is included into the command procedure triggered from
APL_INIT_1 event channel. An example snapshot is as follows:
;APL_INIT_1:C in HSB systems for WD application
...
#do STOP_OPC_DA_CLIENT_INSTANCE:C ;Stop previous External OPC DA
Client instance
#exec_after 10 START_OPC_DA_CLIENT_INSTANCE:C ;Start OPC client after a delay

The application logic for handling External OPC Data Access client stopping and starting
has been included into a separate command procedures in the WD application. The reason
for stopping the External OPC Data Access client is related to the situation that Micro-
SCADA Pro SYS 600 may have been stopped abnormally due to some computer failure.
In these circumstances the standard routines related to the shutdown of SYS 600 base
system's SHUTDOWN.CIN execution nor stopping of application (APL_CLOSE event
channel execution) has been handled normally.

An example of these command procedures is given below.

;STOP_OPC_DA_CLIENT_INSTANCE:C in HSB systems for WD application
...
@opc_status = ops_call("C:\sc\prog\OPC_Client\DA_Client\daopccl.exe -id ""conf""
-stop", 0)

;START_OPC_DA_CLIENT_INSTANCE:C in HSB systems for WD application

...
@opc_status = ops_call("C:\sc\prog\OPC_Client\DA_Client\daopccl.exe -id ""conf""
-start ""C:\sc\sys\active\sys_\config.ini"" -trace normal", 0)

For detailed information about the usage of DAOPCCL.EXE and its parameters, see
SYS 600 External OPC Data Access Client.

4.9.2.2. Activating station communication

Before the OPC item updates are propagated to the MicroSCADA Pro SYS 600 process
database, there is a need to activate the communication station(s) included into External
OPC DA Client configuration. In a hot stand-by system, this should be made by the main
application. Typically this application logic is included in the command procedure
triggered from APL_INIT_1 and APL_INIT_H event channels.
;APL_INIT_1:C / APL_INIT_H:C in HSB systems for MAIN application
...
#exec STAS_IN_USE:C

141
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

The station communication can be activated as described in the following command

procedure:
;STAS_IN_USE:C in HSB systems for MAIN application
...
#error continue

@i_Sta_Numbers = (81,82,83,84,85)
#loop_with lc = 1..length(%i_Sta_Numbers)
@i_Sta_Number = %i_Sta_Numbers(%lc)
#set sta'i_Sta_Number':sIU = 1 ;station in use
#set sta'i_Sta_Number':sUP = 1 ;update points
#loop_end

4.9.3. Hot stand-by with PC-NET

In communication protocols supported by the PC-NET process communication unit, the

switch over situation in HSB concept requires SCIL programmable actions. This will
guarantee the communication to continue in the HOT system without interruptions. When
the system goes to stand-by mode, it deactivates the communication to stations and in
case of slave protocols, also to NCCs. Correspondingly, when the system goes to HOT
state, the communication to the stations and NCCs is activated. The PC-NET processes
are running all the time, including when system is in stand-by mode.

4.9.3.1. PC-NET configuration

The PC-NET configuration made with the System Configuration Tool should be entered
from the watchdog (WD) application. With this approach, the configured PC-NET
instances are automatically started when MicroSCADA is started and the PC-NET
instances are already configured when the MAIN application goes “hot” in all situations.

When the system configuration is entered from the WD application, the AS and MS
attributes of the STA objects created for the PC-NET will also refer to WD application.
The AS attribute defines the application that will receive process data messages and the
MS defines the application where the system messages from the station object will be
sent for. In order to map the incoming process data and the status messages to the main
application, the following configuration should be entered to the configuration of the
NET node. In this example, the number of the main application is 1 and the number of
the WD application is 2.

142
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

A071120

Figure 4.9.3.1-1 System Configuration Tool window

An alternative method is to add the following script to the "User-Defined" program of

the NET node.
@MAIN_APL = 1
@WD_APL = 2

#SET NET'i_Net_Number':SSY'WD_APL'= (SYS:BND, %MAIN_APL)

#SET NET'i_Net_Number':SSY'MAIN_APL'= (SYS:BND, %WD_APL)

This script should be present in HSB configuration, otherwise the process data will be
sent to the WD application. Furthermore, all lines created to PC-NET process commu-
nication units should be configured to have IU=0, which means, all lines should be out
of use by default.

4.9.3.2. Activating communication

The communication to the station and to NCCs should be activated when state of the
main application turns to HOT. In practise, a command procedure attached to event
channels APL_INIT_1 and APL_INIT_H of the main application should loop all lines
created to PC-NET nodes and take the line into use.

The LON protocol (if created to the system) requires special handling. With LON protocol,
it is required that the stations objects should be taken into use after the line has been

143
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

taken into use. In practise, this means that all the mentioned procedure should contain a
block.
#SET NET3:SIU1 = 1 ;LON line 1 in NET3
#SET STA20:SIU = 1 ;REX station connected to LON line 1
#SET STA21:SIU = 1 ;REX station connected to LON line 1
.
#SET STA80:SIU = 1 ;LMK station connected to LON line 1

No other station types, except “REX” and “LMK”, need to

be taken out of use and back to use when the communication
activation and deactivation is required to perform.

The event channel APL_INIT_1 in the main application is executed when system is
started and the state of the main application is "HOT" immediately after the startup.
APL_INIT_1 is not executed in normal take-over. The event channel APL_INIT_H is
activated when the take-over occurs and the state of the main application changes from
"COLD" to "HOT". For more information about the predefined event channels
APL_INIT_1 and APL_INIT_H, see SYS 600 Application Objects.

With the COM 500i application, the communication activation

procedure should be executed before the COM_COMINI_H
and COM_COMINI procedures in APL_INIT_H and
APL_INIT_1.

4.9.3.3. Deactivating communication

When the main application turns to COLD state, it necessary to deactivate all communic-
ation. The deactivation is made from a commands procedure connected to event channel
APL_CLOSE of the main application. The behaviour is opposite compared with the
activation presented in the previous chapter.

Like in the activation, the LON protocol (if created to the system) requires special
handling. In this case, it is required that the stations objects should be taken out of use,
before the line has been taken into use.
#SET STA20:SIU = 0 ;REX station connected to LON line 1
#SET STA21:SIU = 0 ;REX station connected to LON line 1
.
#SET STA80:SIU = 0 ;LMK station connected to LON line 1
#SET NET3:SIU1 = 0 ;LON line 1 in NET3

144
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

No other station types, except REX and LMK, are needed to

be taken out of use and back to use, when the communication
activation and deactivation are required to be performed.

4.9.4. Hot stand-by with CDC-II slave

In the HSB setup with CDC-II slave, similar configuration is made to both computers
of the HSB pair, according to the instructions in SYS 600 CDC-II Slave Protocol.

The principles of starting the CDC-II slave instances as well as the communication
activation and deactivation in takeover situations are similar to 4.9.5, Hot stand-by with
Modbus slave.

If there is only one instance, it may be useless to divide the

configuration files and the executable itself to the subdirector-
ies as instructed for modbus slave.

Like in other process communication units, the activation and the deactivation of the
communication should be made from command procedures executed from event channels
APL_INIT_1, APL_INIT_H and APL_CLOSE of the main application.

The communication activation procedure should be executed

before the COM_COMINI_H and COM_COMINI procedures
in APL_INIT_H and APL_INIT_1.

4.9.5. Hot stand-by with Modbus slave

In the HSB setup with modbus slave, the basic idea is that, when the system goes to
stand-by state, the communication is deactivated by killing the instances of MOD-
BUS_SLAVE.EXE. When the system is started or the main application goes from COLD
to HOT state, the communication is activated by starting the modbus slave instances.

This approach is different from the description in Modbus slave protocol manual of
MicroSCADA. However, shutting down the instance is required in hot stand-by setup,
in order to control the fallback switches of the NCC line correctly.

4.9.5.1. Modbus slave configuration

This example should be applied to required amount of Modbus slave lines, that is, NCC
connections from COM 500i. The following steps are required to configure 3 modbus
slave lines:

145
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

1. Create the following directories:

• \sc\prog\modbus_slave\s1

• \sc\prog\modbus_slave\s2

• \sc\prog\modbus_slave\s3

2. Copy MODBUS_SLAVE.EXE and CONFIG.INI to each of these created director-

ies.

3. Rename the MODBUS_SLAVE.EXE to MDS1.EXE, MDS2.EXE and MDS3.EXE.

The renaming is needed in order to shut down the instances

in a controlled way. If there is only one instance of the modbus
slave, the renaming is not necessary and the shutting down
(Step 6) can be done using the name MODBUS_SLAVE.EXE.

4. Edit the "CONFIG.INI" in each directory and make the corresponding configuration
to the base system, as instructed in Modbus Slave Protocol manual of MicroSCADA.
The number of the main application should be given to the configuration item
"application_number".

5. Create a BAT-file MDS1.BAT with the following contents:

cd C:\sc\prog\modbus_slave\s1
mds1

Create a similar BAT-file for each instance to their own subdirectory.

6. Add the following script to a code procedure executed from event channels
APL_INIT_1 and APL_INIT_H of the main application.
;MD_SLAVE_START:C

@MDS1_STATUS = OPS_CALL("C:\sc\prog\modbus_slave\s1\MDS1.BAT",0)
@MDS2_STATUS = OPS_CALL("C:\sc\prog\modbus_slave\s2\MDS2.BAT",0)
@MDS3_STATUS = OPS_CALL("C:\sc\prog\modbus_slave\s3\MDS3.BAT",0)

7. Add the following script to a code procedure executed from event channel
APL_CLOSE of the main application.
;MD_SLAVE_STOP:C

@MDS1_STATUS = OPS_CALL("taskkill /IM mds1.exe /F",0)

@MDS2_STATUS = OPS_CALL("taskkill /IM mds2.exe /F",0)
@MDS3_STATUS = OPS_CALL("taskkill /IM mds3.exe /F",0)

146
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

8. Define the NCC connections to the Signal X-reference tool in the base system. The
entered RTU station numbers should be equal to values entered to CONFIG.INI files,
item stn_no_1.

COM 500i initializes the modbus databases in the order NCC1,

NCC2. and so on. If some of the modbus slaves requires faster
communication start-up after a takeover, it is preferred to
configure it to a smaller NCC number compared to others.

4.9.5.2. Activating communication

The communication to the NCCs will be activated when the state of the main application
turns to HOT. In this situation, if the configuration step 5 in 4.9.5.1, Modbus slave con-
figuration is completed, instances MDS1.EXE, MDS2.EXE and MDS3.EXE should be
found from the process list of the computer. The operation of each of these instance can
be tested as instructed in Modbus Slave Protocol manual.

Furthermore, the starting and the stopping of the modbus instances can be tested by
executing the command procedures mentioned in step 5 and 6 (in 4.9.5.1, Modbus slave
configuration).

The event channel APL_INIT_1 is executed when system is started and the state of the
main application is HOT immediately after the start-up. APL_INIT_1 is not executed
in normal take-over. The event channel APL_INIT_H is activated when the state of the
main application changes from COLD to HOT. For more information about the predefined
event channels APL_INIT_1 and APL_INIT_H, refer to the Application Objects manual.

The communication activation procedure should be executed

before the COM_COMINI_H and COM_COMINI procedures
in APL_INIT_H and APL_INIT_1.

4.9.5.3. Deactivating communication

When the main application turns to COLD state, it necessary to deactivate all communic-
ation. In this situation, if the configuration step 6 is completed as instructed, instances
MDS1.EXE, MDS2.EXE and MDS3.EXE will disappear from the process list of the
computer and the communication to the NCCs are at least temporarily stopped.

For more information about the predefined event channel APL_CLOSE, refer to the
Application Objects manual.

147
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

4.9.6. Hot stand-by with CPI applications

The general requirement in the HSB setup with CPI applications is that if the takeover
occurs, the CPI application instances in computer going from HOT to COLD should not
disturb the communication of the system which is going to HOT state.

In practice, the following rules should be applied:

1. In all serial line protocols, the DTR pin of the used serial port should be set to non-
signaled state when the main application goes to COLD state. Correspondingly, the
DTR pin of the used serial port should be set to signaled state when the main
application goes to HOT state. The controlling of the DTR pin is needed to control
the fallback-switches between the application and the remote device. If the CPI
application instance provides an attribute which controls the DTR pin and also
activates/deactivates the communication, this attribute can be used from the pre-
defined event channels APL_INIT_1, APL_INIT_H and APL_CLOSE, using the
logic described in 4.9.3, Hot stand-by with PC-NET. If the CPI application instance
does not provide an attribute which controls the DTR pin and the communication,
the killing of the instance while the system is in stand-by state may be necessary.
In this situation, the runtime behaviour follows the idea presented in 4.9.5, Hot
stand-by with Modbus slave.
2. In all LAN protocols operating as TCP/IP client or using UDP/IP, all communication
to the remote devices should be deactivated when the system is in stand-by state.
In a remote device, any communication from the stand-by system may disturb the
communication with the adjacent HOT system. Whether the CPI-application provides
the runtime control for this or not, the principles presented in rule 1 should be used.
3. In all LAN protocols operating as TCP/IP server, the listening socket of the protocol
should be deactivated while the system is in stand-by state or at least the CPI-
application should close the TCP connection as quickly as possible in this state. Any
activity in this state will make the selection algorithm in remote end more complicated
and slower. If the CPI application does not provide control for the listening socket,
killing of the instance while the system is in stand-by state may be necessary.

The rules 2 and 3 need not to be followed if it is known that

the remote device is capable to handle concurrent connections.

With the COM 500i application, the communication activation

procedure should be executed before the COM_COMINI_H
and COM_COMINI procedures in APL_INIT_H and
APL_INIT_1.

148
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

4.9.7. Hot stand-by with communication gateway COM 500i

This chapter describes the principles of the HSB concept in systems including COM
500I communication gateway.

Figure 4.9.7-1 is a typical HSB system with gateway functionality. Both COM 500I
computers consist of their own SYS 600 base system and COM 500I gateway function-
ality. When a fault occurs in the primary base system including the HOT application,
the shadowing application in the stand-by base system is started and it takes over all the
operational functions. For more information, see 4.9.1, Hot stand-by base systems.

A070469

Figure 4.9.7-1 Typical HSB system with COM 500I

Limitations

• No keep-alive connection from NCCs to stand-by COM 500i

• Switch is initiated by the hot stand-by application of COM 500i and not by the NCCs
• Events can be lost or doubled when switch-over occurs in COM 500i

149
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

4.9.7.1. Configuring communication gateway COM 500i

SYS_BASCON.COM

Set the variable COM 500 to TRUE for each COM 500i application in
SYS_BASCON.COM.
#local COM500 = vector(TRUE) ;TRUE = COM500i application,
;FALSE = not COM500i application

APL_INIT_H

APL_INIT_H is activated when the switch-over occurs and the state of the main
application changes from COLD to HOT. COM 500i writes automatically command
#DO COM_COMINI_H:C to APL_INIT_H command procedure, when the main
application is opened the first time after installation. The COM_COMINI_H command
procedure starts initialization of COM 500i after switch-over (as shown in Figure 4.9.7.1-
1).

150
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

A071121

Figure 4.9.7.1-1 Initialisation of COM 500i after switchover

Communication units

For more information, see Communication units configuring in 4.9.2, Hot stand-by with
OPC client and servers, 4.9.3, Hot stand-by with PC-NET, 4.9.4, Hot stand-by with
CDC-II slave, 4.9.5, Hot stand-by with Modbus slave and 4.9.6, Hot stand-by with CPI
applications.

Parameters page of signal X-Reference

NET initialization switchover delay

This defines the time (second) after which the initialization of the protocol converters
in NET started. This parameter should be set to be the time from switchover to the
moment when all the NET lines and stations have been set to in use. The default value
is 0 s.

151
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

Database initialization switchover time

This defines the time in seconds after which NET database initialisation is started (DNP
3.0 and RP 570) and Database Initialized message in sent to the NCCs IEC 60870-5-
101/104. The default value is 0 s.

A071122

Figure 4.9.7.1-2 Hot stand-by timeout information

4.10. Configuring mirroring

Process database mirroring is defined on station (STA:B) object level: a station in SYS
600 that is connected to a PC-NET or some other data source, the host station, is connected
to one or more image stations located in other applications, usually in other MicroSCADA
Pro machines.

One host station can have up to 10 image stations. In a hierarchical mirroring system,
each image station can in turn act as a host to upper-level image stations. The role of a
station object and its mapping to a station located in the external application are defined
by a couple of station object attributes.

The application containing the host station is called host application (of the station) and
the application containing the image station is called the image application (of the station).
Note however that an application can have both host and image stations, so it can act in
different roles for different stations.

The process objects of a host station and an image station are mapped according to their
object address (OA and OB) or source name (IN or IN/EH of OPC based objects). If the
object address or the source name of a process object is identical in the host and image
database, the objects are considered to denote the same signal in the station device. The
logical names of the process objects can be different in different databases.

All the process objects in an image database that are in use (IU = 1) have the switch state
AUTO (SS = 2) and map to an in-use AUTO state process object in a host database, are
subject for mirroring. No new process object attributes are used to configure mirroring
communication.

An image application subscribes to the events of process objects in its process database.
The image database can only contain a subset of addresses found in the host database,
the uninteresting signals can be dropped from the communication load.

The mirroring function contains the following sub-functions:

152
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

1. The host application replicates the messages from the station device to each image
application that has subscribed to the object address.
2. The process commands (#SET and #GET) executed in an image application are
routed to be executed by the host application. The changed OV value is sent to the
image applications by the host.
3. Any access of STA:S attributes in an image application is routed to be executed by
the host application.
4. The host application replicates the system messages from the NET to each image
application that has subscribed to the system messages.

The mirroring communication between the host and image application is implemented
as APL-APL communication. Consequently, LAN, WAN and serial communication can
be used. The APL-APL communication between the host and image applications must
be configured to enable mirroring.

The communication between the host and the image is buffered and the communication
breaks are handled automatically. The events that have occurred during the break are
sent when the connection is re-established.

The hot stand-by configurations are supported and the switch overs are handled automat-
ically without losing any events.

Mirroring can be disabled or enabled on a host/image application pair basis by means

of APL object attributes. When mirroring is disabled, the host buffers events, just as
during other types of communication breaks.

Significant mirroring events, such as established or lost connections and configuration

mismatches, are reported to the application via application events (event channels
APL_EVENT and HOST_ADDRESS_MISSING).

Diagnostic counters, implemented as APL object attributes, help monitoring the traffic
between the host and image application.

Because it is possible to create very large image applications by using the mirroring
function, the maximum number of STA base system objects (MAX_STATION_NUMBER
in SCIL) is 50 000.

4.10.1. Station mapping

There are three station (STA:B) attributes that define the role and addressing of the station
in the mirroring network. The MR (Mirroring Role) attribute defines the role of the station:

• MR = HOST: This is a host station that transmits the process data to one or more
image stations defined by the attribute IS
• MR = IMAGE: This is an image station that receives the process data from the host
station defined by the attribute HS

153
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

• MR = BOTH: This is an image station that receives the process data from the host
station defined by the attribute HS. Furthermore, it acts as a host station to the image
stations defined by the attribute IS
• MR = NONE: This station does not participate in mirroring (default)

The HS (host station) attribute of an image station object defines where the corresponding
host station is to be found. It has a list value with the following attributes:

APL The number of the (usually external) host

application
UN The unit number of the host station in the host
application

The IS (Image Stations) attribute of a host station object defines where the corresponding
image stations are found. The attribute is a vector of up to 10 list values with the following
attributes:

APL The number of the (usually external) image

application
UN The unit number of the image station in the
image application

4.10.2. Process messages

In principle, all the messages from the station device to the host database are replicated
by the host database and sent to the image applications that have subscribed to the object
address. For the load control, however, some measurement events can have been dropped.
For more information, see 4.10.7, Buffering and communication breaks. In a hierarchical
mirroring network, the image application can also act as a host and re-replicate the
messages and send them further to their upper-level image applications.

The substituted values of the process objects (the ones written by SCIL along with the
SU attribute) are handled as real process values, that is, they are subject to the mirroring
as well. This feature can be used to send mirroring events by SCIL. Define an AUTO
state process object with a pseudo-address (an address having no real counterpart in the
process station) and write to it by using the following notation:
#SET ABC:P1 = LIST(OV = 1, SU = 1)

4.10.3. Process commands

Process commands, that is #GET commands and #SET commands of the OV (BO, DO,
AO or BS) attribute of an AUTO state process object, are sent to the host application
which executes them on behalf of the image application. In a hierarchical mirroring
network, the commands are delivered to the lowest level host. If the command is success-
ful, the new OV value is distributed as a mirroring event to the host database and all the

154
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

image databases. If it is unsuccessful, the status of the failed command is returned to the
controlling SCIL program in the image application.

When a process command is executed by the host application, the new OV value is
mirrored to all image databases.

4.10.4. System object (STA:S) communication

Evaluation of STA:S object attributes in an image application, as well as the SET com-
mand (#SET) and GET command (#GET), is routed via the mirroring mechanism to the
lowest level host application, which executes the request on behalf of the image applic-
ation. The results (the status of SET and GET command and the result of evaluation) are
back-routed to the image application. The host database and other image applications
are affected only if the setting/getting/evaluation indirectly generates messages from the
station.

Because of the routing via the mirroring mechanism, the tools that communicate with a
station via its system object attributes may be run in an image application without any
SCIL code changes.

4.10.5. System messages

System messages from the NET are delivered to image applications in a similar way as
process messages. The difference in configuration is that in the host application the
system messages are always sent to virtual unit number 0.

In the image application, a non-zero unit number must be reserved for each host whose
system messages are received. This unit then represents the virtual unit 0 of the host. As
in process messages, the process objects within this unit and the host unit 0 are mapped
by their object addresses. In the STA object of the image database, the unit is mapped
to unit 0 of the host application by setting HS = LIST(APL = host_application, UN =
0). When the image application starts up, it subscribes to the system messages (object
addresses) of the unit in the same way as it subscribes to the process messages.

In the host application, no STA objects related to system message mirroring are needed
because system messages are always received to unit 0. Instead, the image stations which
receive system messages are listed in a new application attribute IS (Image Stations for
System Messages).

The IS attribute of the host application is similar to the IS attribute of a host station. It
is a vector of up to 10 list values, which define the image stations mapped to the system
messages of this host application.

155
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

4.10.6. Subscriptions

The communication between the host and image is subscription-based. When the image
application successfully connects to the host, it scans through its process database and
sends a list of object addresses that it is interested in, that is the addresses that:

• Are in use
• Are in AUTO switch state
• Belong to a unit (station) that is connected to the host.

When the host receives a subscription, it immediately sends back the current value of
the object (with CT, cause of transmission, set to INTERROGATED). If the requested
object address is not found in the host database, an ADDRESS_MISSING event is sent
back.

An address is unsubscribed when a mirrored process object in the image database is:

• Deleted
• Turned out of use
• Set out of switch state AUTO

On the other hand, when an in-use AUTO object is created, the image application auto-
matically subscribes to its events.

When an object with subscriptions to it is deleted or its state switched from in-use AUTO
state in the host database, an ADDRESS_MISSING event is sent to all the subscribers.
When a new process object is created (or switched to in-use AUTO state), a
NEW_ADDRESS event is sent to the image applications. They can then decide to sub-
scribe to its events.

The database of the image application can only be a subset of the host database, thereby
reducing the required communication rate.

Each image application does its own subscription. The subscriptions can be different.

4.10.7. Buffering and communication breaks

The events to be sent to image applications are buffered by the host system. Each external
application that serves as an image application in mirroring has its own event queue.

• The EM attribute (Event Queue Length Maximum) of the application defines the
maximum length of the queue.
• The EU attribute (Event Queue Used) shows the current length of the queue.
• The EP attribute of the APL object (Event Queue Overflow Policy) specifies the
policy to be followed when the maximum length is reached.

Two different event queue overflow policies are defined below:

156
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

• EP = DISCARD: The queue is destroyed, an overflow message is sent to the image

and the communication is stalled. In this case, the image application does a general
interrogation to the host database, but some events can be lost.
• EP = KEEP: The events are not allowed to be lost. In this case, the process commu-
nication between the host application and PC-NET is slowed down just as if the EU
attribute of the host application would have reached EM.

The KEEP policy is considered only during the established communication between the
host and image. If the limit is reached during a communication break, the DISCARD
policy is used.

When the connection to the image application is lost, the host only buffers events without
trying to send them. When the image application (or its HSB partner, if there has been
a take-over at image site) succeeds in re-establishing the connection, it sends the sequence
number of the last received message to the host and requests retransmitting of newer
events. If the host still has the requested events in its buffer, it sends them and no events
are lost.

If the requested events are no longer available because queue length reached its maximum
during the break or because the host has been down, the image application does a new
subscription and events can be lost.

During a communication break, the process objects in the image database are marked
as old by setting the object status value to 2.

The load control in the communication is done by reducing the rate of measurement
events. Measurement event means a process message to an analog input process object
when all the following conditions are met:

• The object has a real value representation. Integer valued AI objects, that is the ones
with IR = 1, are not considered as measurements.
• The event is a measurement event according to the load control policy of the station.
• The object address is not included in the list of analog event addresses (attribute
AE) of the station.

The LP (Load Control Policy) attribute of the station (STA:B) object defines which
analog events can be considered as measurement events according to the description
above. The attribute can take one of the following four values:

"KEEP_ALL_ANALOGS" No analog messages are taken as measure-

ments.
"KEEP_TIME_STAMPED_ANALOGS" The messages that are not time-stamped by
the station are taken as measurements.
"KEEP_NO_ANALOGS" The analog messages are taken as measure-
ments whether they are time-stamped or not.
"DEFAULT" The LP attribute of the corresponding STY
object is applied.

157
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

The station type (STY) objects have a similar LP attribute as well. STY:BLP defines the
default policy for all the stations of the type.

For the station types, which have the DB attribute value STA, the DEFAULT policy is
equivalent to KEEP_TIME_STAMPED_ANALOGS. Otherwise the default policy is
KEEP_NO_ANALOGS. For more information about the LP attribute of station and
station type objects, see SYS 600 System Objects.

The AE (Analog Events) attribute of the station (STA:B) object is defined in the host
system. Its value is an integer or text vector of any length and it contains a list of the
analog input object addresses (OA) or OPC item names (IN) within the station that are
not to be taken as measurements in the sense described above.

4.10.8. Hot stand-by

HSB switchovers are automatically taken care of and no SCIL command procedures are
involved.

To be able to do this, the base system should know which external applications make up
an HSB pair. Therefore, the SN (Shadowing Number) attribute of the external applications
that participate in mirroring should be set. Either of the two applications numbers can
be defined as the APL attribute of the HS or IS attribute of the stations participating in
the mirroring.

For example, if in an image system the external host applications 7 and 8 make up an
HSB pair, the SN attribute of APL7 should be set to 8 and the SN attribute of APL8
should be set to 7. Either 7 or 8 can be defined as the APL attribute of the HS attribute
of the stations located in the host.

No events are lost due to HSB switch-overs because the mirroring event queues are
shadowed by the host application and the events are sequence-numbered. After an HSB
switchover of the host or the image application, the image application asks the host to
retransmit all the events that are newer than the last received event.

4.10.9. Disabling mirroring

In an image system, the mirroring communication with a particular host application can
be temporarily disabled by setting the HE (Host Enabled) attribute of the host's APL
object to 0. Mirroring is re-enabled by setting the attribute back to 1.

In a host system, the mirroring communication with a particular image application can
be temporarily disabled by setting the IE (Image Enabled) attribute of the image's APL
object to 0. Mirroring is re-enabled by setting the attribute back to 1.

158
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

While the mirroring is disabled, the host buffers events breaks, just like during other
types of communication, and sends them to the image when the mirroring is enabled
again.

4.10.10. Application events

Various significant mirroring events are reported to the application via application event
channels APL_EVENT and HOST_ADDRESS_MISSING. For full description of these
event channels, see SYS 600 Application Objects.

HOST_ADDRESS_MISSING is used in an image application to log the object addresses

that according to the image database should be mirrored but are not found in the host
database.

APL_EVENT is used both in the host and in the image application.

The events reported by the event channel in the image application are the following:

Source Event Description

"UN" "MISSING" The connection to the host sta-

tion cannot be established
because of a mismatch in STA
object configuration between
the image and the host.
"LOST" The connection to the host sta-
tion is lost because the mirror-
ing configuration (either MR or
IS) in the host has been
changed.
"FOUND" The connection to the host sta-
tion is established because the
mirroring configuration in the
host has been changed.
"HOST_LOST" A "LOST" event for the unit has
occurred in the intermediate
level host. This event is gener-
ated instead of the "LOST" unit
to tell the application that there
is nothing wrong with the mirror-
ing configuration between this
application and the intermedi-
ate level application, but the
configuration mismatch is
detected on a lower level.
"HOST_FOUND" The configuration problem
lower in the mirroring hierarchy
has been fixed.
"HOST" "CONNECTED" The connection to the host is
established.

159
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

Source Event Description

"LOST" The connection to the host is

lost.
"DISCONNECTED" The connection to the host has
been lost because there are no
stations connected to the host
anymore.
"RECONNECTED" The connection to the host is
re-established without losing
any events.
"OVERFLOW" The event buffer of the host
has overflown. Events have
been lost.
"DOWN" The connection to the host has
been disconnected by the host,
because the host application is
shutting down.
"DISABLED" The communication with the
host has been disabled by set-
ting APL:BHE to 0.
"ENABLED" The communication with the
host has been enabled by set-
ting APL:BHE to 1.
"HOST_DISABLED" The communication with the
host has been disabled by the
host (by setting APL:BIE to 0).
"HOST_ENABLED" The communication with the
host has been enabled by the
host (by setting APL:BIE to 1).

The events reported by the event channel in the host application are the following:

Source Event Description

"IMAGE" "CONNECTED" The connection to the image is

established.
"LOST" The connection to the image is
lost.
"DISCONNECTED" The image application has dis-
connected the mirroring ses-
sion.
"RECONNECTED" The connection to the image is
re-established without losing
any events.
"OVERFLOW" The event buffer for the image
has overflown. Events have
been lost.

160
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

Source Event Description

"BLOCKING" The event buffer for the image

is full, but because of the
defined event queue overflow
policy "KEEP", the buffer is not
discarded. The connection is
now blocking (or slowing down)
the communication between
the SYS and the NET in order
not to lose any events in the
image application.
"NON_BLOCKING" The event buffer for the image
is not full anymore. The connec-
tion does not slow down the
communication between the
SYS and the NET anymore.
This event is generated when
the length of the event queue
(EU) has dropped below 90 %
of its maximum (EM).
"DISABLED" The communication with the
image has been disabled by
setting APL:BIE to 0.
"ENABLED" The communication with the
image has been enabled by
setting APL:BIE to 1.
"IMAGE_DISABLED" The communication with the
image has been disabled by
the image (by setting APL:BHE
to 0).
"IMAGE_ENABLED" The communication with the
image has been enabled by the
image (by setting APL:BHE to
1).

4.10.11. Configuration examples

The main steps of the mirroring configuration procedure are the following:

1. Create a node for each base system in the mirroring system (and a LAN link).
2. Create an external application for each image in the host system and an external
application for each host in the image system.
3. Define the mirroring attributes for each station; the mirroring role (MR) of a station,
the image stations (IS) which are to receive events from the host for the host stations
and the host station (HS) for image stations.
4. Raise the amount of APL-APL servers (APL:BAA) of each mirroring application
to 10. In most real applications, a lower value would do as well, but the cost of 10
servers is low compared to finding out the smallest usable value. If, however, a

161
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

lower value is preferred, the following rule can be used. In a host application set the
APL:BAA attribute to 10 or two times the number of connected image applications,
whichever is lower. In an image application, set the AA attribute to 10 or two times
the number of connected host applications, whichever is lower.
5. Copy/create the process objects of the image application.

The process database of the image system can be a subset of the host process database.
All process objects, which are of interest, can be copied from the host to the image.

Five example configurations are described in the following. The first example describes
a simple system where process events are mirrored from a host to an image. Second case
is an example of a system where a redundant image system receives process events from
several hosts. Station numbering convention is demonstrated in case 3. Example 4
demonstrates local mirroring and case 5 is an example of hierarchical mirroring.

4.10.11.1. Example 1: One host, one image

A051613

Figure 4.10.11.1-1 Simple mirroring system

This is a basic configuration. Process database events of a host base system are mirrored
to an image base system.

Configuring the host base system

The configuration of the host base system is described first. Mirroring requires base
system node and external application additions in SYS_BASCON.COM. A LAN link,
link number 1, is assumed to exist already. In this example, the node number of the host
base system is 232 and the node name is SYS_H. The node number of the image base
system is 228 and the node name is SYS_I.

A base system node for the image:

#CREATE NOD228:B = LIST(- ;Node for SYS_I
LI = 1,-
NN = “SYS_I“,-
SA = 228)

162
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

An external application to represent the image:

#CREATE APL2:B = LIST(-
TT = “EXTERNAL“,-
NA = “IMAGE1“,-
ND = 228,-
TN = 1)

Mirroring attributes of the host stations can be defined in the user-defined programs of
the System Configuration Tool. The definition can be written in the user-defined program
of each station, or definitions can be grouped in the user-defined program of the net
node. If the System Configuration Tool is not used, the mirroring attributes can be defined
in SYS_BASCON.COM. The definition should be written for each mirroring station;
the definitions for unit 51 serve as an example in the following:
#SET STA51:BMR = “HOST“
#SET STA51:BIS = VECTOR(LIST(APL=2, UN=51))

The host application is connected to one image application, so there should be at least
two APL-APL servers.
#SET APL1:BAA = 2

Now the host part of the mirroring configuration is ready.

Configuring the image base system

A base system node for the host:

#CREATE NOD232:B = LIST(- ;Node for SYS_H
LI = 1,-
NN = “SYS_H“,-
SA = 232)

An external application to represent the host:

#CREATE APL2:B = LIST(-
TT = “EXTERNAL“,-
NA = “HOST1“,-
ND = 232,-
TN = 1)

The mirroring configuration additions of the stations in the image base system can be
written in SYS_BASCON.COM.

Mirroring attributes for stations (station 51 as an example):

#SET STA51:BMR = “IMAGE“
#SET STA51:BHS = LIST(APL=2, UN=51)

The image application receives messages from one host, which defines that the number
of APL-APL servers should be at least 2.
#SET APL1:BAA = 2

163
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

Now the configuration of the image system is ready. Both base systems can now be
started and the process objects which are of interest are copied from the host to the image.

System messages

Some additional configuration is required to get the system messages from the NET to
the image. In the host application, the attribute IS should be defined to introduce the
image station which is to receive system messages.
#SET APL1:BIS = vector(list(APL=2, UN=91))

In the image system the respective station, here unit number 91, should be created to
receive system messages from the host.
#CREATE STA91:B = LIST(-
TT = “EXTERNAL“,-
ST = “RTU“,-
MR = “IMAGE“,-
HS = LIST(APL=2, UN=0)
TN = 91)

This unit 91 in the image base system now represents the virtual unit 0 of the host, and
system messages from the NET are delivered to the image application.

4.10.11.2. Example 2: Two hosts, redundant image

A051614

Figure 4.10.11.2-1 Redundant image, two hosts

In this example a redundant image base system receives process updates from two host
base systems.

164
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

• The node number of the image base system 1 is 228 and the node name is SYS_I1.
• The node number of the redundant image base system 2 is 229 and the node name
is SYS_I2.
• The node number of the host 1 base system is 232 and the node name is SYS_H1
• The node number of the host 2 base system is 233 and the host name is SYS_H2

The configuration of host base systems is presented first.

Configuring the host base system

The base system nodes for the image base systems are required and should be created
in SYS_BASCON.COM of each host base system.
#CREATE NOD228:B = LIST(- ;Node for SYS_I1
LI = 1,-
NN = “SYS_I1“,-
SA = 228)

#CREATE NOD229:B = LIST(- ;Node for SYS_I2

LI = 1,-
NN = “SYS_I2“,-
SA = 229)

An external application should be created for each image. The following code is added
in SYS_BASCON.COM of each host base system. Note the attribute SN which defines
the application number of the shadowing partner. Here the external applications 2 and
3 make up a HSB pair.
#CREATE APL2:B = LIST(-
TT = “EXTERNAL“,-
NA = “IMAGE1“,-
ND = 228,-
SN = 3,- ;Shadowing partner
TN = 1)

#CREATE APL3:B = LIST(-

TT = “EXTERNAL“,-
NA = “IMAGE2“,-
ND = 229,-
SN = 2,- ;Shadowing partner
TN = 1)

Mirroring attributes of the host stations can be defined in the user-defined programs of
the System Configuration Tool. The definition can be written in the user-defined program
of each station, or definitions can be grouped in the user-defined program of the net
node. If the System Configuration Tool is not used, the mirroring attributes can be defined
in SYS_BASCON.COM. The definition should be written for each mirroring station;
an example of the definitions for unit 51 is given below:
#SET STA51:BMR = “HOST“
#SET STA51:BIS = VECTOR(LIST(APL=2, UN=51))

The host application serves one image application, so there should be at least two APL-
APL servers.

165
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

#SET APL1:BAA = 2

Now the mirroring configuration of the hosts is completed.

Configuring the redundant image base system

Make the modifications in one configuration file and then copy the results to the config-
uration file of the redundant base system.

A node should be created for each host base system.

#CREATE NOD232:B = LIST(- ;Node for host 1 (SYS_H1)
LI = 1,-
NN = “SYS_H1“,-
SA = 232)

#CREATE NOD233:B = LIST(- ;Node for host 2 (SYS_H2)

LI = 1,-
NN = “SYS_H2“,-
SA = 233)
An external application should be created for each host base system.
#CREATE APL5:B = LIST(-
TT = “EXTERNAL“,-
NA = “HOST1“,-
ND = 232,-
TN = 1)

#CREATE APL6:B = LIST(-

TT = “EXTERNAL“,-
NA = “HOST2“,-
ND = 233-
TN = 1)

The mirroring configuration additions of the stations for the image base systems can be
written in SYS_BASCON.COM.

Mirroring attributes for the stations, here the configuration for stations 51 and 53, is
presented as an example. Station 51 receives messages from host 1 and station 53 from
host 2.
#SET STA51:BMR = “IMAGE“
#SET STA51:BHS = LIST(APL=5, UN=51)

#SET STA53:BMR = “IMAGE“

#SET STA53:BHS = LIST(APL=6, UN=53)

The image application receives messages from two hosts, so there should be at least four
APL-APL servers.
#SET APL1:BAA = 4

The mirroring configuration of the image base systems is now ready. All base systems
can now be started and process objects can be copied from the hosts to the hot image.

Overlapping unit numbers

166
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

In a mirroring system where process events are gathered from several existing hosts it
is possible that the same unit number exists in several hosts. Therefore, after the process
objects have been copied, the overlapping unit numbers should be changed in the image
application. When defining mirroring attributes for the station, this should be noticed in
the host base system .

For example if unit 2 exists both in host 1 and host 2, the unit number of the process
objects from host 2 should be changed to any valid value which is not in use. Here the
new unit number in the image application can be 3.

The mirroring definitions for station 2 are:

#SET STA2:BMR = “HOST“
#SET STA2:BIS = VECTOR(LIST(APL=2, UN=2))

in host 1 and
#SET STA2:BMR = "HOST"
#SET STA2:BIS = VECTOR(LIST(APL=2, UN=3))

in host 2.

In the image base system a new STA object, station 3, should be created with the
appropriate mirroring attribute values:
#CREATE STA3:B = LIST(-
TT = “EXTERNAL“,-
ST = “RTU“,-
MR = “IMAGE“,-
HS = LIST(APL=6, UN=2)
TN = 3)

4.10.11.3. Example 3: Station numbering convention in a mirroring system

This example illustrates the configuration of a system where the same unit number is
used in several hosts and messages coming from these units are delivered to one applic-
ation in an image base system.

167
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

A071292

Figure 4.10.11.3-1 Same unit number in n image applications

Configuring the host base system

Mirroring-related configurations for host 1 (SCS_1).

#CREATE LIN:V = LIST(- ;Link to other SYS or LAN frontend
LT = "LAN") ;Link type
#CREATE LIN2:B = %LIN

#CREATE NOD228:B = LIST(- ;Node for NCC

LI = 2,-
NN = "192.168.10.228",- ;if name used, remember define \etc\HOSTS -table
SA = 228)

#CREATE APL2:B = LIST(- ;Mirroring image appl.

TT = "EXTERNAL",-
NA = "IMAGE1",-
ND = 228,-
TN = 1)

#SET STA9:BMR = "HOST"

#SET STA9:BIS = VECTOR(LIST(APL=2, UN=109)

Number of APL-APL servers.

#SET APL1:BAA = 2

168
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

Mirroring-related configurations for host ‘n’ (SCS_’n’).

#CREATE LIN:V = LIST(- ;Link to other SYS or LAN frontend
LT = "LAN") ;Link type
#CREATE LIN2:B = %LIN

#CREATE NOD228:B = LIST(- ;Node for SYS

LI = 2,-
NN = "192.168.10.228",- ;if name used, remember define \etc\HOSTS -table
SA = 228)

#CREATE APL2:B = LIST(- ;Mirroring image appl.

TT = "EXTERNAL",-
NA = "IMAGE1",-
ND = 228,-
TN = 1)

#SET STA9:BMR = "HOST"

#SET STA9:BIS = VECTOR(LIST(APL=2, UN=709)); UN=100x’n’+STA’nr’

Number of APL-APL servers.

#SET APL1:BAA = 2

Configuring the image base system

Mirroring-related configurations for the image.

#CREATE LIN:V = LIST(- ;Link to other SYS or LAN frontend
LT = "LAN") ;Link type
#CREATE LIN2:B = %LIN

#CREATE NOD231:B = LIST(- ;Node for SCS_1

LI = 2,-
NN = "192.168.10.231",- ;if name used, remember define \etc\HOSTS -table
SA = 231)

....
#CREATE NOD237:B = LIST(- ;Node for SCS_’n’
LI = 2,-
NN = "192.168.10.237",- ;if name used, remember define \etc\HOSTS -table
SA = 237) ;SA=230+’n’

#CREATE APL3:B = LIST(- ;Mirroring host appl.

TT = "EXTERNAL",-
NA = "SCS_1",-
ND = 231,-
TN = 1) ;Appl. number

....
#CREATE APL7:B = LIST(- ;Mirroring host appl.
TT = "EXTERNAL",-
NA = "SCS_7",- ;’n’=7
ND = 237,- ;230+’n’
TN = 1) ;Appl. number

Station STA109 receives messages from unit 9 of host 1 (SCS_1) and STA209 from unit
9 of host 2 (SCS_2).

169
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

#SET STA109:BMR = "IMAGE"

#SET STA109:BHS = LIST(APL=3, UN=9)

#SET STA209:BMR = "IMAGE"

#SET STA209:BHS = LIST(APL=4, UN=9)

#SET STA309:BMR = "IMAGE"

#SET STA309:BHS = LIST(APL=5, UN=9)
....
#SET STA709:BMR = "IMAGE"
#SET STA709:BHS = LIST(APL=7, UN=9)

Number of APL-APL servers.

#SET APL1:BAA = 10

Because it is possible to create very large image applications by using the mirroring
function, the maximum number of STA base system objects (MAX_STATION_NUMBER
in SCIL) is 5000.

4.10.11.4. Example 4: Local mirroring

Both the host and the image are in the same base system. One application is the host
application connected to the process, and the other is the image application. In addition
to the stations connected to the process, the corresponding image stations must be created
as well. In this example, the image station number is 1000 + host stations number.

Mirroring configuration of the host

Mirroring attributes of the host stations can be defined in the user-defined programs of
the System Configuration Tool. The definition can be written in the user-defined program
of each station, or definitions can be grouped in the user-defined program of the net
node. The definition must be done for each mirroring station. An example of the defini-
tions for unit 51 is given below:
#SET STA51:BMR = “HOST“
#SET STA51:BIS = VECTOR(LIST(APL=2, UN=1051))

Mirroring configuration of the image

Mirroring attributes of the image stations can be defined in the configuration file
SYS_BASCON.COM.

The station 1051 receives messages from the host station 51 in application 1. Therefore,
the mirroring attributes for station 1051 are the following:
#SET STA1051:BMR = “IMAGE“
#SET STA1051:BHS = LIST(APL=1,UN=51)

170
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

4.10.11.5. Example 5: Hierarchical mirroring

In this example, the node number of the substation base system is 232, and the node
name is SUBS. The regional control center base system node number is 230, and the
node name is REGIONCC. Finally, the main control center base system node number
is 228, and the node name is MAINCC.

Mirroring attributes can be defined in the user-defined programs of the System Config-
uration Tool. The definition can be written in the user-defined program of each station,
or definitions can be grouped in the use-defined program of the net node. The definition
must be done for each mirroring station. See an example of the definitions for unit 51
below.

Mirroring definitions in the substation:

This is the host base system.

#SET STA51:BMR = “HOST“
#SET STA51:BIS = VECTOR(LIST(APL=2, UN=51))

Create an external application (image).

#CREATE APL2:B = LIST(-
TT = “EXTERNAL“,-
NA = “REGION“,-
ND = 230,-
TN = 1)

Create a node for the image.

#CREATE NOD230:B = LIST(- ;Node for the Regional Control Center
LI = 1,-
DI = 10,-
DT = 5,-
DF = 1,-
NN = “REGIONCC“,-
SA = 230)

Now the mirroring configuration of the substation is ready.

Mirroring definitions of the regional control center

The units in the regional control center can both receive messages from the substation
(the host) and transmit messages to the main control center (image). The mirroring role
MR of such stations must be "BOTH".

Mirroring attributes for station 51:

#SET STA51:BMR = “BOTH“
#SET STA51:BHS = LIST(APL=2, UN=51)
#SET STA51:BIS = VECTOR(LIST(APL=3, UN=51))

Create two external applications, one for the image and another for the host.

171
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

#CREATE APL2:B = LIST(-

TT = “EXTERNAL“,-
NA = “SUBS“,-
ND = 232,-
TN = 1)

#CREATE APL3:B = LIST(-

TT = “EXTERNAL“,-
NA = “MAIN“,-
ND = 228,-
TN = 1)

Create nodes.
#CREATE NOD228:B = LIST(- ;Node for the Main Control Center
LI = 1,-
DI = 10,-
DT = 5,-
DF = 1,-
NN = “MAINCC“,-
SA = 228)

#CREATE NOD232:B = LIST(- ;Node for the Substation

LI = 1,-
DI = 10,-
DT = 5,-
DF = 1,-
NN = “SUBS“,-
SA = 232)

Now the mirroring configuration of the regional control center is ready.

Mirroring definitions of the main control center

Image configuration additions can be written in SYS_BASCON.COM of the main control

center base system. The node number of the base system is 228, and the node name is
MAINCC.

Mirroring attributes for station 51

#SET STA51:BMR = “IMAGE“
#SET STA51:BHS = LIST(APL=2, UN=51

Create an external application for the regional control center (host).

#CREATE APL2:B = LIST(-
TT = “EXTERNAL“,-
NA = “REGION“,-
ND = 230,-
TN = 1)

Create a node for the host

#CREATE NOD230:B = LIST(- ;Node for the Regional Control Center
LI = 1,-
DI = 10,-
DT = 5,-
DF = 1,-

172
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

NN = “REGIONCC“,-
SA = 230)

Now the main control center configuration is ready as well.

4.11. Configuring OPC connectivity

The usage of OPC communication between OPC client and server requires that Distributed
COM (DCOM) has been configured accordingly in the Windows operating systems.

The following figure describes all the different locations, where OPC connectivity can
be reached via OPC client and server software with the SYS 600.

A071132

Figure 4.11-1 OPC Summary

4.11.1. DCOM settings

During the SYS 600 installation, the DCOM settings for the usage of OPC communication
has been configured automatically into the target computer.

173
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

The role of DCOM settings is to make distributed applications secure by using the
extensible security framework provided by Windows operating systems. This is possible
via storing the access control lists for detailed components into registry of target computer.
It is possible to see the DCOM settings by using the DCOM configuration tool (Start >
Run > DCOMCNFG). The following chapters describe the detailed steps required for
the DCOM settings.

4.11.1.1. Enabling of Distributed COM

Default DCOM settings for client and server applications can be adjusted by following
the instructions given below:

1. Click Start > Settings Control Panel > Administrative Tools.

2. Select Component Services. Expand the Component Services > Computers
container.
3. Right-click My Computer, and then click Properties.
4. Select Default Properties tab, and set Distributed COM enabled on this computer.
5. Set the Default Authentication Level as Connect and Default Impersonation Level
as Identify.

When you set the authentication level to Connect, verify the

following:

• the user logged in to the OPC client computer is logged in as a domain user and not
a local user.
• the OPC server computer actually belongs to the domain. If it's a standalone com-
puter, it cannot authenticate the users unless you have a matching user name/password
on both the OPC client and OPC server computer.

4.11.1.2. Defining access permissions

When the OPC client tries to access the OPC server, the COM security permissions
defined by the Windows operating system will be applied.

These permissions are defined in the COM Security tab of My Computer Properties
(as mentioned in 4.11.1.1, Enabling of Distributed COM).

1. Select COM Security tab > Access Permissions > Edit Limits.
2. Allow both local and remote access permissions to Anonymous Logon, Everyone,
Interactive, Network and System groups > OK.
3. Click Access Permissions > Edit Default.
4. Allow both local and remote access permissions to Anonymous Logon, Everyone,
Interactive, Network and System groups > OK.

174
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

4.11.1.3. Defining launch and activation permissions

When OPC client performs launch and activation towards the OPC Server, for example,
automatic DCOM server start-up, then the COM security permissions defined by the
Windows operating system will be applied. These permissions are defined in the COM
Security tab of My Computer Properties (steps mentioned in 4.11.1.1, Enabling of Dis-
tributed COM).

1. Select COM Security > Launch and Activation Permissions > Edit Limits.
2. Allow both local and remote access permissions to Anonymous Logon, Everyone,
Interactive, Network and System groups. Click OK.
3. Click Launch and Activation Permissions > Edit Default.
4. Allow both local and remote access permissions to Anonymous Logon, Everyone,
Interactive, Network and System groups. Click OK.

4.11.1.4. Defining DCOM settings for OPC servers

Each OPC server has its own DCOM settings for controlling access to this particular
server.

1. Click Start > Settings Control Panel > Administrative Tools.

2. Click Component Services. Expand the Component Services > Computers > My
Computer container.
3. Select the DCOM Config, and then browse to your OPC Server, right-click on it,
and select Properties.
4. Select General tab, set the Authentication Level to Connect.
5. Select Security tab > set Customize > Access Permissions > Edit.
6. Depending on the selected server do the following:
a. For ABB MicroSCADA OPC DA Server and ABB MicroSCADA OPC A&E
Server, deny both local and remote launch permissions to Everyone, Interactive,
Network and System groups and allow both local and remote activation permissions
to Everyone, Interactive, Network and System groups > OK.
b. For other OPC servers, allow both local and remote access permissions to
Everyone, Interactive, Network and System groups > OK.
7. Set Customize option > Access Permissions > Edit.
8. Allow both local and remote access permissions to Everyone, Interactive, Network
and System groups > OK.
9. Select Identity tab. Verify that the user information has been defined correctly. If
not, choose the MicroSCADA user and enter its password > OK.

4.11.1.5. Defining DCOM settings for OPC Server Enumerator

OPC Server Enumerator (OpcEnum) is a server application used by OPC clients to

remotely find OPC servers on a computer. This requires proper DCOM configuration
for OpcEnum.

175
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

If OpcEnum is not found from the DCOM Config list, it

means that the component has not been installed. If there is
need to install this component, the appropriate installation file
can be found from the following location after SYS 600
installation: \sc\Setup\OPC_Core_Components. Copy this file to
the target OPC client computer, and double-click the Windows
Installer Package file.

1. Select the OpcEnum from the list of DCOM Config, right-click on it, and select
Properties.
2. Select the General tab, set the Authentication Level to Connect.
3. Select the Security tab > set Customize option > Launch and Activation Permis-
sions > Edit.
4. Allow both local and remote launch and activation permissions to Everyone, Inter-
active, Network and System groups > OK.
5. Set Customize option > click Access Permissions > Edit.
6. Allow both local and remote launch and activation permissions to Everyone, Inter-
active, Network and System groups > OK.
7. Select Identity tab, verify that OpcEnum is either run by the launching user or the
system account > OK. The DCOM settings on the target machine are now correct.

4.11.2. Local Security Policy settings

The following steps may need to be taken in order to establish OPC communication:

These changes may compromise the security of your system.

If this happens, contact your network administrator.

1. Select Start > Settings > Control Panel > Administrative Tools > Local Security
Policy.
2. Expand the Security Settings > Local Policies > Security Options container.
3. Select Network access: Let Everyone permissions apply to anonymous users.
Right-click on it, and select Properties.
4. Select Enabled > OK.
5. Select Network access: Sharing and security model for local accounts. Right-
click on it, and select Properties.
6. Select Classic - local users authenticate as themselves > OK.

4.12. Configuring Process Display Note links

You can configure whether links are enabled and whether the adding/removing of links
is possible.

176
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

To configure links:
1. Click the Process Display Note object. A Process Display Note dialog is displayed.
2. Click Configure in the Process Display Note dialog (button available only for system
managers).

A071353

Figure 4.12-1 The Process Display Note dialog

3. The Customize Note dialog opens.

A071309

Figure 4.12-2 The Customize Note dialog

4. Select whether you want to enable or disable links and click OK. If support for
modifying links is disabled, the Add and Remove buttons in the Note Links dialog
are disabled.

4.13. Icon storage and configuration

Icons are stored in the \sc\sa_lib\defaults\icons\ folder. Each icon file includes all of the
needed icon sizes. The application specific .ini file [appl]\par\apl\framewindow.ini defines
the icon mappings, that is, which icons belong to which menu items and toolbar buttons.

If definitions are not found in the application specific ini-file, the global .ini file
\sc\prog\sa_lib\default_framewindow.ini is used.

The section name is MPROICONS, the key name is the icon file name and the key value
is the menu or toolbar button id, see the example below:
[MPROICONS]

177
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

AlarmDisplayTemplate1.ico=32900,32902

The icon size is also defined in the ini-file. The system checks first the user specific file,
and if no definitions are found the application specific file is checked and then the global
ini-file definitions. For icon size definitions there is a possibility for system or user specific
definitions. If user specific values are not defined (no value found), the system specific
values are used. The section name is MPROICONSIZE, see example below.
[MPROICONSIZE]

IconsSize=16x16

The key name is IconSize. Possible size definitions are 16x16, 24x24, and 32x32.

4.13.1. Customizing icon mappings

To find out the menu item or toolbar button id:

1. Open the Customize dialog by selecting Settings > Customize.
2. Click on some menu item or toolbar button.
3. Add icon mapping to framewindow.ini (see 4.13, Icon storage and configuration).

The id can be seen on the status bar as numeric presentation, for example 62227 in Fig-
ure 4.13.1-1.

A070021

Figure 4.13.1-1 Icon ID on status bar

It is also possible to define an icon graphic for the disabled state of menu items or toolbar
buttons. This is done by defining an icon with the same name as the active state icon,
but adding a string "Disabled" into the name. For example, corresponding to the
AcknowledgeAlarm.ico icon file there is a file named AcknowledgeAlarmDisabled.ico
to handle the disabled state of the icon. All icons are defined in the
\sc\sa_lib\defaults\icons\ folder. We recommend using and defining disabled state of
icons as well, to make the presentation of the disabled state of the icon or toolbar button
more clear.

Icons can be reset by selecting Reset Icons... from the Settings menu. When this is done,
all the icon files in the \sc\sa_lib\defaults\icons\ folder are checked and the mapping to
each menu item and toolbar button is done based on the information found in
\sc\prog\sa_lib\default_FrameWindow.ini file as explained above.

4.14. Configuring Customize Search dialog

It is possible to make more specific configurations to the dialog in the Monitor Pro-
Customize Search dialog. The configurations are global, that is, they affect all users.

178
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

Configuring requires system administrator user rights. With the correct authorization
the Configure... button in the Search dialog is enabled.

To configure the Process Display search:

1.
Open the Monitor Pro - Search dialog by clicking the icon on the Process
Display toolbar. The Search dialog opens.
2. Click the Configure... button, see Figure 4.14-1. The Monitor Pro - Customize Search
dialog opens.

A070014

Figure 4.14-1 Customize Search dialog

3. Set the configuration in the Customize Search dialog, see Fig. 4.2.-6. The following
options are available:
• Remember dialog placement (session specific): When this box is checked
Monitor Pro opens the dialog to the same location during the whole session
until logout.
• Zoom level default value: Defines the zoom level used when the located object
is selected from the result row and viewed in the Process Display.
• Result with coordinates: Checking this box makes the coordinates of the object
visible on the Search dialog result row.
• Result with OPC Item ID: Checking this box makes the OPC Item ID visible
on the result row.
• Auto-select result row: When this box checked and one of the First/Last radio
buttons is selected, either the first or last result row is automatically selected in
the Search dialog results. You can also check the Zoom automatically box to
make Monitor Pro automatically zoom on the selected result.
4. Click OK to take the configurations into use.

179
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

4.15. Changing Login and About Monitor Pro dialog graphics

The bitmap (ABB logo) for the Login and About Monitor Pro dialogs is created based
on file \sc\sa_lib\defaults\misc\DialogLogo.bmp. If the bitmap is replaced, the new
bitmap dimensions should be 382(width) x 72(height).

4.16. Configuring login dialog shortcut key

You can create a shortcut for the login dialog by defining the shortcut key in [SHORT-
CUT] of the \sc\prog\sa_lib\default_framewindow.ini file:
[SHORTCUTS]
;Keyboard shortcut for showing the login dialog (Ctrl+[character]). If not
defined using the default value Ctrl+L
LoginDlg=

180
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

5. Configuration tools

5.1. System Configuration Wizard

The System Configuration Wizard offers a tool for a user to configure the elementary
information of a single or hot stand-by system even if the project engineer is not familiar
with the SCIL language. To start the wizard, complete the following steps.

1. Open the SYS 600 Control Panel.

2. Click Admin.
3. Click Wizard.
4. The System Configuration Wizard dialog is displayed. Click Next.
5. The license information of the current system is displayed on the next dialog. Click
Next.
6. The actual configuration starts on the next dialog. Select the base system type. To
configure a single system, select Single System. To build a hot stand-by system,
select Hot Stand-by System. The OPC Server is normally enabled.

A071315

Figure 5.1-1 Base system type selection

5.2. Configuring single base system

To configure a single base system:
1. Select the option Single System.

181
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

2. On the next dialog, enter the base system node name, node number and station
address of the base system node.

A071316

Figure 5.2-1 Single base system information

3. Enter the application name. In case of a COM 500i application, select the option
COM 500i Application enabled. If the OPC Alarms and Events server is required,
select OPC Alarms and Events Server enabled.

182
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

A071317

Figure 5.2-2 Application information
4. You have now entered all the required information for the elementary configuration
of a single base system. The system is ready to be started. The wizard starts the
system, if you select the option Start the application.

183
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

A071318

Figure 5.2-3 Single base system configuration finished

5.3. Configuring hot stand-by base system

To configure a hot stand-by system:
1. Select the base system type Hot Stand-by System.

184
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

A071315

Figure 5.3-1 Base system type selection

2. Enter the node name, node number and station address for both base systems. Select
one of the two base systems as the current node.

A071320

Figure 5.3-2 Hot Stand-by system information

185
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

3. The next dialog defines the application information. In case of a COM 500i applic-
ation, select the option COM500i Application enabled. If the OPC Alarms and
Events server is required, select OPC Alarms and Events Server enabled.

A071321

Figure 5.3-3 Application information
4. You have now entered all the required information for the elementary configuration
of a hot stand-by base system. The system is ready to be started. The wizard starts
the system, if you select the option Start the application.

186
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

A071322

Figure 5.3-4 Hot Stand-by system configuration finished

If an upgrade project the old SYS_BASCON.COM is not compatible with the wizard,
the following dialog will be displayed. Select Yes and the configuration will continue
as described above.

A071323

Figure 5.3-5 Incompatible SYS_BASCON.COM dialog

The wizard writes the configuration information into the SYS_BASCON.COM file. The
lines inside the block Quick configuration are affected.
;File: Sys_bascon.com
;Desription: Standard Base system configuration file

187
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

; for Single and Hot Stand-By systems

; Version 9.3
;----------------------------------------------------
;
;The quick configuration block below is written by the configuration wizard or
;it can be modified manually.
;
;Quick configuration begin
;
#local Hot_Standby = TRUE ;Hot Stand-by enabled/disabled
#local Apl_Names = vector("MAIN") ;Application Name vector, main
applications
#local BS_Names = vector("SYSTEM_A","SYSTEM_B") ;Base System Node Names
#local BS_Nodes = vector(9,10) ;Base System Node Numbers
#local BS_Addresses = vector(209,210) ;Base System Station Addresses
#local This_Node_is = BS_Nodes(1) ;This system 1 or 2 (Always 1 for single
system)
;
#local COM500 = vector(TRUE) ;TRUE = COM500i application,
;FALSE = not COM500i application
#local OPC_Server_Enabled = TRUE ;OPC Server enabled/disabled
#local OPC_AE_Server_Enabled = vector(TRUE) ;OPC A&E Server enabled/disabled
;
;Quick configuration end
;

The wizard also saves the configuration into the SYS_BASCON.INI file.
[System Type]
Hot_Standby=TRUE
OPCS=TRUE
This_Node=1
[Base System]
Address=209
Node=9
Name=SYSTEM_A
[Base System 2]
Address=210
Node=10
Name=SYSTEM_B
[Application]
Name=MAIN
Number=1
COM500=TRUE
OPC_AE=TRUE

When the wizard is started it reads the contents of the SYS_BASCON.INI file. The
wizard does not read the SYS_BASCON.COM file. Thus it does not recognize modific-
ations, which are made in SYS_BASCON.COM with Notepad or any other editor.

5.4. System Configuration Tool

The System Configuration Tool is used for configuring the IEC 61850 and PC-NET
communication engines in MicroSCADA Pro system. The main purpose is to have all
system configuration for communication engines collected to one common tool in the
system.

188
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

5.4.1. Starting System Configuration Tool

To start the System Configuration Tool, follow the steps given below:

1. Click the System Configuration tab in the SYS 600 Tool Manager dialog.
2. Double-click the System Conf tool icon, as shown in Figure 5.4.1-1.

A051809

Figure 5.4.1-1 System Configuration Tool icon

The System Configuration Tool dialog includes a menubar and a toolbar. To make the
toolbar visible, select Settings > Toolbar Visible. Below the toolbar, there is an object
tree on the left side, an attribute tree in the middle and an attribute editing area on the
right side. In addition to these, there is an information text bar and a status bar at the
bottom of the page, as shown in Figure 5.4.1-2.

189
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

A051810

Figure 5.4.1-2 System Configuration Tool dialog

5.4.2. Handling objects and attributes

When you select an object from the object tree and if All Attributes is selected as the
View option, all the attributes linked to it are shown in the attribute tree (as shown in
Figure 5.4.2-1).

The tool gives default values to the attributes.

190
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

A071348

Figure 5.4.2-1 MicroSCADA Pro Configuration item attributes in the expanded attribute tree

The working order from left to right:

1. Select an object in the Object Tree.
2. Click the + button under the attribute tree to expand all the attribute groups.
3. Select the attribute that you want to configure.
4. Change the value in the editing area.
5. Press Enter.

In the attribute editing area, the on/off values have a check box. A clear check box
indicates Off (0) and a selected check box indicates On (1). For integer values, there is
a numeric spin box in the editing area, as shown in Figure 5.4.2-2.

The attribute tree is updated, when changes are made in the editing area.

191
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

A051812

Figure 5.4.2-2 Editing the PS attribute value with the numeric spin box

If the value in the editing area is dimmed, editing is not

allowed.

5.4.2.1. NET Node station address

For communication units, the default SA attribute value is 200 + node number. If node
number is set bigger than 55, the default SA attribute value set by the System Configur-
ation Tool is 255.

5.4.3. Saving configurations

If a configuration from a former MicroSCADA release is read into the System Configur-
ation Tool, it can be saved with the Configuration > Save Active command. The con-
figuration is saved in the following default files: SYSCONF.INI and SIGNALS.INI.

The configuration is available when MicroSCADA 8.4.2 or subsequent

SYS_BASCON.COM (sys_bascon$com) template is in use.

5.4.4. Creating a new configuration

From the menu bar, select Configuration > New. This command opens a configuration
that is delivered with the System Configuration Tool. It includes an Object tree with
Link 1 (LAN), Link 3 (INTEGRATED) and Node 3 (NET), as shown in Figure 5.4.4-1.

192
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

A071349

Figure 5.4.4-1 New configuration

If a configuration is already open in the tool, the entire configuration data is cleared from
the tool and the contents of the Object tree is replaced with the default configuration. To
save the open configuration, copy or rename the SYSCONF.INI and SIGNALS.INI files
in the sys/active/sys_ folder.

5.4.4.1. Adding new objects

1. From the object tree, select a parent object for the new object, as shown in Fig-
ure 5.4.4.1-1.

A051813

Figure 5.4.4.1-1 Node 3 (NET) selected to be the parent object

2. After selecting a parent object, there are three ways of adding objects to the config-
uration.

193
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

Use one of the following methods:

• Keyboard command Ctrl+N
• Menu bar command Object > New, as shown in Figure 5.4.4.1-2.

A051814

Figure 5.4.4.1-2 New object is added by using the menu bar command

• Click the Object creation tool icon in the toolbar

Figure 5.4.4.1-3 New object icon

3. Select the object type and click Insert.

A051816

Figure 5.4.4.1-4 LON Line is added to the configuration

4. Enter the object number in the text box and click OK, as shown in Figure 5.4.4.1-
5.

A051817

Figure 5.4.4.1-5 Number five is entered for the new line object

The new object is added to the object tree.

194
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

Figure 5.4.4.1-6 The new line in the object tree

5.4.4.2. Deleting objects

Objects can be deleted by following the steps given below:

1. Select the object from the Object tree.

2. Click the Object menu from the menu bar.
3. Select the object and click Delete.

If the object includes user-defined SCIL programs or signals, they are deleted as well.

A051819

Figure 5.4.4.2-1 Station 2 is deleted

The main object (MicroSCADA Configuration object) cannot

be deleted.

5.4.4.3. Adding a redundant line

The tool supports adding redundant line for IEC 60870-5-101 slave and RP570 slave
lines.

1. Select the IEC 870-5-101 Slave Line or RP570 Slave Line from the object tree.
2. Select Object > Add Redundancy, as shown in Figure 5.4.4.3-1.

195
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

A051820

Figure 5.4.4.3-1 Adding a redundant line

3. Enter the line number of the redundant line in the field, as shown in Figure 5.4.4.3-
2.

A051821

Figure 5.4.4.3-2 Enter the line number of the redundant line

The redundant line is added to the object tree, as shown in Figure 5.4.4.3-3.

A051822

Figure 5.4.4.3-3 Redundant line configuration

5.4.4.4. Deleting a redundant line

1. To delete a redundant line (IEC 870-5-101 slave or RP570 slave), select the line
you want to delete, as shown in Figure 5.4.4.4-1.
2. Select Object > Remove Redundancy from the menu bar, as shown in Fig-
ure 5.4.4.4-1.

196
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

A051823

Figure 5.4.4.4-1 Deleting a redundant line

5.4.5. Configuring dial-up

Some communication lines, for example ANSI X3.28, can be configured to use a dial-
up communication. Dial-up protocols are identified in the New Object list when commu-
nication line is added to the configuration. In the object tree, an icon is used for dial-up
representation and a set of autodialling attributes can be seen in the attribute tree for the
selected dial-up communication line, as shown in Figure 5.4.5-1.

A060290

Figure 5.4.5-1 Dial-up configuration

197
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

In online mode, the auto-caller state information is displayed on the Diagnostics page.
It can be used for the dial-up communication line.

If the specified communication port does not contain a modem

or the modem is switched off, the communication line cannot
be successfully configured into the communication system
(PC-NET). When this occurs, the status codes 10003
NETP_TIMEOUT_WHILE_WAITING_ACKNOWLEDGE or 152
SCIL_NET_COMMUNICATION_TIMEOUT are displayed in the SYS
600 Notification dialog during the configuration.

5.4.6. Station redundancy

The implementation of station redundancy is described in SYS 600 9.3 System Objects.

The System Configuration Tool supports configuring the redundancy attributes of primary
and secondary STA objects and supports adding proxy STA objects.

5.4.6.1. Configuring primary and secondary stations

The tool includes Redundancy Attributes view. Redundancy role (RR) and proxy station
number (RS) define primary and secondary stations.

A071354

Figure 5.4.6.1-1 Redundancy Attributes

198
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

5.4.6.2. Adding a proxy STA object

To add a proxy STA object:

1. Add the Proxy Station level by selecting Object > New > Proxy Station, and then
Insert.

A071355

Figure 5.4.6.2-1 Proxy Station level

2. Add a proxy station by selecting Object > New, and then select the appropriate
station type and enter the station number.
3. Define the primary station (PS) and the secondary station (SS) for it.

199
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

A071356

Figure 5.4.6.2-2 Proxy station configuration

5.4.7. Configuring IEC 61850

The tool supports configuration of the IEC 61850 base system objects.

To configure the IEC 61850 base system objects:

1. Select Link 1 [LAN] from the Object tree.
2. Select Object > New from the menu bar.
3. Select IEC 61850 Node object and click Insert.
4. Enter the object number, for example, 2 in the text box and click OK.
5. Select Node 2 [IEC 61850] from the Object tree.
6. Select Object > New from the menu bar.
7. Select IEC 61850 Station object and click Insert.
8. Enter the object number, e.g. 2 in the text box and click OK.

Repeat the steps 7 and 8 above for adding as many IEC 61850 Stations as there are IEDs
connected to External OPC DA Client Configuration Tool. After adding IEC 61850
Stations 12, 22, 32 and 42, the configuration appears as shown in Figure 5.4.7-1.

200
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

A071332

Figure 5.4.7-1 IEC 61850 base system object configuration

Each instance of the External OPC DA Client communication

engine represents the collection of the IEC 61850 Node object
and one or multiple IEC 61850 Stations. If the system contains
multiple instances of External OPC DA Clients, then the
appropriate number of IEC 61850 Node objects has to be
added to LAN Link.

The configuration of LAN Link object (LIN:B) with the

appropriate number should always be included in the
SYS_BASCON.COM file. Due to the characteristics of LAN
Link object, the tool will not create this object when configur-
ing the MicroSCADA system. The appearance of LAN Link
object in the tool indicates the object relationships within the
system configuration.

For more information on the External OPC DA Client configuration, see External OPC
Data Access Client manual.

5.4.8. Saving as a default configuration

The default configuration is stored in a configuration file called SYSCONF.INI.

To open the default configuration file, select Configuration > Open Active. The default
configuration is loaded in the tool.

The tool opens in the off-line mode, which is shown in the status bar.

201
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

To save a configuration as the default configuration, select Configuration > Save Active.
The configuration currently open in the tool is saved as the default configuration in the
SYSCONF.INI file.

The configuration can be saved at any time and this action can be done in both online
and off-line mode.

To restore the previous configuration, select Configuration > Restore Previous Con-
figuration.

A071324

Figure 5.4.8-1 Restore previous configuration

5.4.9. Online configuration

The online configuration is the current running configuration in the SYS 600 system.

5.4.9.1. Loading online configuration

You can load the current SYS 600 system configuration in the tool either all at once or
stepwise, node by node.

To load the current configuration all at once, select Configuration > Open Online >
All, as shown in Figure 5.4.9.1-1.

202
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

A071326

Figure 5.4.9.1-1 Open Online configuration 1

Loading the online configuration all at once can be a lengthy operation under the following
circumstances:

• When the configuration consists a great amount of devices

• When number of devices are located behind slow communication lines or do not
respond at all

Thus, it is recommended to open the current online configuration stepwise, for example,
the actual loading is not done until the node is expanded. To load the current configuration
step by step, select Configuration > Open Online > Stepwise, as shown in Fig-
ure 5.4.9.1-2.

A071327

Figure 5.4.9.1-2 Open Online configuration 2

After either of the above action, the System Configuration Tool is changed to the online
mode. The background color of the object and attribute trees are set to "Lavender" and
the text in the lower-right corner is changed to “Online” when the online mode is selected.

Under MicroSCADA Configuration node there is a node called Station Type Definitions,
as shown in Figure 5.4.9.1-3. This object includes all the different station types, which
are displayed when the Station Type Definitions node is expanded. It is not possible to
delete this object.

203
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

A070489

Figure 5.4.9.1-3 Station type definitions in the online configuration

5.4.9.2. Saving online configuration

If the online configuration is loaded using the method Configuration > Open Online
> All, it can be saved using the command Configuration > Save Active. The following
notification dialog is displayed on the window:

A070490

Figure 5.4.9.2-1 Dialog informing the user that saving online configuration overrides current
configuration files

204
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

• Click Yes to override the current active configuration in the System Configuration
Tool and save the online configuration as the default configuration.
• Click No to cancel the saving operation. If the menu bar command Configuration
> Save Active is selected, the configuration should include a Link object and a NET
Node object related to the Link.

If the INTEGRATED Link object and NET Node object are

not included in the object tree, the PC-NET does not start up
successfully. The tool informs the user about the invalid PC-
NET configuration, see Figure 5.4.9.2-1. You can save the
configuration where only IEC 61850 Node objects are included
by clicking Yes. If the configuration must be valid for PC-
NET, click No and add the necessary objects to the object
tree.

5.4.10. Taking configuration in use and out of use

When taking LONWORKS lines and stations in use in the PC-NET, it is essential for
the line to be taken in use before any station (on that specific line) is taken in use. Like-
wise, all the stations must be taken out of use before the line is taken out of use.

To take the configuration in use, it is required to change the IU attribute values to In Use
mode in the System Configuration Tool.

1. From the menu bar, select Configuration > Open Active if the configuration is not
open already.
2. In the Object tree, select the line you want to take in use.

A051825

Figure 5.4.10-1 LON line number five is selected in the Object tree

3. Double-click the text Basic Line Attributes or click the + sign in the Attribute tree.
This expands the Basic Line Attributes group and shows all the attributes in it.

205
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

A051826

Figure 5.4.10-2 Line five (LON) attribute groups

4. If the IU (In Use) attribute value is 0 (Not In Use), change it to 1 (In Use) in the
following way:
• In the Attribute tree, click the IU attribute line.
• In the attribute editing area, select the IU check box (In Use state).

A051827

Figure 5.4.10-3 IU Attribute in the In Use (1) state

5. Select Configuration > Save Active from the menu bar.

After you have taken the line in use, you can take the stations in that line in use as well.

5.4.11. Reallocating stations

It is possible to cut, copy and paste the already defined objects in the configuration tree.
When you cut an object, it is also deleted from the configuration tree.

During the cutting/copying and pasting action, all the related information is copied and
reallocated. This includes attribute values, possible user-defined SCIL programs (stations,
NET Lines and NET Nodes) and signals (data points for REx, LMK, SPA, STA, PLC
and DNP stations).

5.4.11.1. Cutting and copying stations

1. Select the object you want to cut or copy from the configuration tree.
2. Select Edit > Cut or Edit > Copy from the menubar.

The selected object is cut or copied to the clipboard.

206
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

During cutting/copying the contents of the signal data for the REx, LMK, SPA, STA,
PLC and DNP stations is assigned to the clipboard.

Cutting an object is not possible if the selected object includes

child objects.

5.4.11.2. Pasting stations

1. In the configuration tree, select the parent object for the object on the clipboard.
2. Select Edit > Paste from the menu bar.

The pasted object is a child object for the selected parent object.

During the Edit > Paste sequence, the possible signal data is taken into use from the
clipboard. This concerns REx, LMK, SPA, STA, PLC and DNP stations only.

The System Configuration Tool guards against incorrect configuration: it is not possible
to paste a SPA device directly under a LON line (an LMK device is needed) or to paste
an LMK device under a SPA line.

The configuration object, that is copied into the clipboard, can be pasted several times.
The pasted object number collection is based either on the definition of the minimum
and maximum object numbers (for example from 1 to 10) or on the definition of individual
object numbers (for example 4, 5, 8, 10). The Paste as Range function can be found in
the Edit menu.

A051851

Figure 5.4.11.2-1 Minimum object number is defined to be 1 and the maximum object number

10

If the copied object includes a set of child objects (for example, copied LMK station
includes several SPA stations), the pasting of the object (LMK station) does not include
pasting of the child objects (SPA stations). The child objects are required to be copied
separately.

207
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

System Configuration Tool includes error handling during the

pasting of objects.

5.4.12. Previewing

The contents of a currently open configuration file can be displayed in the tool using the
Preview function. In this function, the data is shown in SCIL clauses.

To show the configuration data, select Configuration > Preview, as shown in Fig-
ure 5.4.12-1. The SCIL clauses are displayed in the SCIL Editor.

A071328

Figure 5.4.12-1 Preview options

SCIL programming is not possible by using the Preview

function.

5.4.13. User-defined programs

It is possible to make user-defined SCIL programs for the NET Node, NET Line and
Stations. With these programs, you can modify lines and process units with features,
which are not yet supported by the configuration tool. For the NET, you can create pro-
tocols and devices, which are not yet supported for the lines in the System Configuration
Tool.

A051626

Figure 5.4.13-1  Symbol for the user-defined programs is disabled

208
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

In the status bar of the System Configuration Tool, there is information for user-defined
SCIL programs with the following meanings:

• If an enabled symbol exists, the selected object includes a user-defined SCIL pro-
gram.
• If a disabled symbol exists, it is possible to include a user-defined SCIL program
for the selected object, but nothing has been attached yet.
• If no symbol exists, it is not possible to include a user-defined SCIL program for
the selected object.

To edit user-defined programs, follow the steps given below:

1. Select the object to be modified.

If the symbol exists in the status bar, you can modify the SCIL program or create a
new one.
2. Select Program > User-Defined, as shown in Figure 5.4.13-2

A051627

Figure 5.4.13-2  SCIL Editor is opened

3. Edit your program using the variables listed in the comments of the program.

A051628

Figure 5.4.13-3  NET3.SCL file in the SCIL Editor

4. Update and exit the program editor.

209
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

5.4.14. Sending general object handling command

This attribute is included in the System Configuration Tool, when the tool is used in the
online mode.

1. Select a REX station in the Object tree.

2. Select Tools > General Object Handling command to open the General Object
Handling command dialog, as shown in Figure 5.4.14-1 and Figure 5.4.14-2.

A051629

Figure 5.4.14-1 General Object Handling command dialog is displayed

3. Type the appropriate values.
4. Click Send to send command to the selected REX station. The Close button closes
the dialog without sending any command.

Example

A051630

Figure 5.4.14-2  General Object Handling command dialog with example values

If you enter the same value definitions that you can see in the dialog above, in Fig-
ure 5.4.14-2, and click Send or press Enter on the keyboard, the following SCIL
command is sent to the REX station number one:
#SET STA1:SGO = (1, 1342, 3, 4, 2, 0, 1)

210
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

5.4.15. Defining general environment definitions

The attribute tree definitions and PC-NET start-up delay time can be set in the Environ-
ment dialog.

A051828

Figure 5.4.15-1 Environment dialog of System Configuration Tool

The setting of delay time for successive PC-NET start-ups has meaning only when more
than one PC-NET is installed, so in a single PC-NET configuration the setting is disabled
in the dialog.

5.4.16. System monitoring

System Self Supervision is always dedicated into certain SYS 600 application, which
includes sets of command procedures, event channels, time channels, process objects,
data objects and parameter files. System Self Supervision functionality can be enabled
in the SYS 600 application by using either of the following ways:

• By installing the Application status standard function from the SA_LIB\Supervision

category
• By selecting the enabled state from the System Self Supervision dialog in the System
Configuration Tool

To open the System Self Supervision dialog, select Settings > System Self Supervision
in the System Configuration Tool, as shown in Figure 5.4.16-1.

211
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

A051829

Figure 5.4.16-1  Enabling and disabling the System Self Supervision

When the System Self Supervision functionality is enabled in SYS 600 application, the
System Configuration Tool does not create supervision routing objects for all the included
configuration objects by default. Hence, the user needs to select the appropriate option
from the dialog. To remove the supervision routing objects from the previously included
configuration objects, it is also required to set that option in the System Self Supervision
dialog.

If no Application status standard function is installed from the SA_LIB\Supervision

category when System Configuration Tool is accessed for the first time and this dialog
is opened, the System Self Supervision is in the disabled state. By default, removing
supervision routing from all the previously included configuration objects requires to
set that option in the System Self Supervision dialog.

If the System Self Supervision dialog is accessed when previous SYS_BASCON.COM

template is being used, an information dialog is displayed. To enable the system self-
supervision routing, it is required to include a new attribute, B_SSS_MECH_IN_USE
in the base system object definition (SYS:B). An example of this attribute can be found
from the new template in the file SYS_BASCON$COM.

A071354

Figure 5.4.16-2  Dialog asking to replace the current SYS_BASCON.COM template to enable

the System Self Supervision

212
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

When the old SYS_BASCON.COM is used during the start-up of SYS 600, the editing
of the System Self Supervision dialog is disabled.

If you are using a new SYS_BASCON.COM template during the start-up of SYS 600,
you can stop and start the run-time supervision routing in the application. To stop and
start the run-time supervision routing, use Run-time supervision routing enabled check
box in the bottom of System Self Supervision dialog. An information dialog displays
the message whether the action was successful or not.

5.4.16.1. Supervision log

The System Configuration Tool includes access to Supervision Log. To enter the
Supervision Log dialog, select Tools > Supervision Log from the menu bar.

The Supervision Log displays all the different events in SYS 600 and the Windows
system. Different log types are:

• Common system messages

• Unknown process objects
• System events from operating system
• Security events from operating system
• Application events from operating system

To select the log type, click Log from the menu bar and select the appropriate log type
from the menu items. For the events shown in the view, there is a possibility to set a
different filter condition, for example, events from a certain station number.

A051831

Figure 5.4.16.1-1 The main view of Supervision Log

213
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

5.4.16.2. Supervision Filter Editor

The Supervision Filter Editor can be used for profiling the appearance of system self
supervision information.

You can open it by selecting Tools > System Self Supervision Filter Editor.

The Supervision Filter Editor displays all the categories supported by the System Self
Supervision functionality:

• Communication lines
• Stations
• Communication nodes
• Printers
• System events
• Operating system events
• Application events
• LON Clock master

The editor is aware of the active system configuration, and displays only the relevant
instances of the communication lines and station types in accordance with the active
configuration.

The appearance of system self supervision profile defines whether the information is
collected as a log entry, or whether the appropriate event appears in the Event and Alarm
List. You can define the settings for each supervision event by selecting the appropriate
check boxes in the tool. The default supervision profile is included in the tool.

A071312

Figure 5.4.16.2-1 SYS 600 Supervision Filter Editor in the System Configuration Tool

214
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

5.4.17. Signal engineering

For some PC-NET station types additional signal engineering information must be con-
figured to get the process objects correctly updated in the MicroSCADA process database.
The signal configuration occurs either by using the subtools, which can be started by
selecting Tools > Signal Engineering, or on the Advanced tab, which appears for STA,
PLC and DNP stations.

The following signal engineering characteristics are supported by the tool:

• SPA points for REx stations
• LON points for LMK stations (including LON Clock Master and LON Star Coupler
devices)
• SPA points for SPA stations
• Memory areas for STA stations
• Topic items for PLC stations
• Data points for DNP stations

System Configuration Tool is integrated to subtools for handling signal information for
stations. For each station type, there is a corresponding configuration tool for managing
signal information. To start the subtools, select Tools > Signal Engineering from the
menu bar. The configuration dialog opens. It includes all the signal information for the
selected station.

To transfer the signal information from the subtool, select Configuration/File > Update
from the subtool’s menu bar. Information is also transferred to the System Configuration
Tool, when Configuration/File > Exit is selected. In each of the subtools, there are
options to cut, copy and paste signal information.

5.4.17.1. Indicator for signal information

In the status bar of the System Configuration Tool, there is an indicator for signal
information with the following meanings:

• If there is an enabled symbol, the selected object includes signal information.

• If there is a disabled symbol, it is possible to include signal information for the
selected object, but no signals are created yet.
• If there is no symbol, it is not possible to include signal information for the selected
object.

A051833

Figure 5.4.17.1-1  Indicator shows that the selected object includes signal information

215
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

The following features are common to all devices:

• When you select a station in the configuration tree, the attribute area is updated.
• Select Tools > Signal Engineering from the menu bar to see the signal information
of the selected station. This operation opens the station Configuration page.
• You can manage the signals with Add, Edit and Delete buttons in the Configuration
page. Signal items can be edited only when the System Configuration Tool is in
offline mode. In online mode the buttons Add, Edit and Delete are disabled and
the signal configuration can be viewed but not modified.

Add/Edit

Add and Edit buttons open the signal Add/Edit dialog for entering or changing the
signal information. The user interface of this dialog depends on the station type.

OK

The OK button accepts the entered values into the signal list of the device and closes
the Add/Edit dialog.

Cancel

The Cancel button cancels the add/edit operation and closes the Add/Edit dialog.

Apply

The Apply button accepts the entered values into the signal list without closing the dialog.

• When a device configuration tool is closed, the signals related to the selected device
are transferred to the System Configuration Tool. When Configuration > Save
Active is selected, these signals are saved into the configuration files and they
become a part of the configuration data. The device signals are interpreted automat-
ically when the NET communication is starting.
• You can see the SCIL commands which are created from the device signals by
selecting Configuration > Preview from the System Configuration Tool menu bar.

To edit the signal information, follow the steps given below:

1. In the Object Tree, select the station to be engineered.

2. Select Tools > Signal Engineering from the menu bar, as shown in Figure 5.4.17.1-
2.

The station configuration page opens for editing.

216
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

A060291

Figure 5.4.17.1-2 The station configuration page is opened

5.4.17.2. REX, LMK and SPA stations

For more information about the signal engineering for the REX, LMK and SPA stations,
see SYS 600 Connecting LONWORKS Devices.

5.4.17.3. Topic configuration for PLC stations

Topic configuration is done in the Advanced page for the PLC stations.

A060292

Figure 5.4.17.3-1 The topic information of a PLC station in the Advanced page of the System
Configuration Tool

217
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

To add a new topic item, click the Add button, which opens the Add Topic Item dialog,
as shown in Figure 5.4.17.3-2. In this dialog, the default topic type is object command
or the type of the last added topic item. The maximum number of topic items for each
device is 100. If the station already includes 100 topic items, the Add button is disabled.

A060299

Figure 5.4.17.3-2 New topic item Object command is added to a PLC station

To delete existing topic items, select the appropriate item in the list and click the Delete
button. Before the deletion is done, a notification dialog is displayed to the user. Clicking
Yes deletes the selected topic item and refreshes the list. Clicking No cancels the delete
operation.

To edit an existing topic item, select the appropriate topic item in the list and click the
Edit button. Editing can also be done by double-clicking the topic item. The selected
topic items are displayed in the Topic Configuration Editor with the existing definitions,
as shown in Figure 5.4.17.3-3. In this dialog, the topic type, allocation, first object address,
last object address, base address, format, interval and deadband are defined.

A060300

Figure 5.4.17.3-3 In this dialog an existing topic item can be edited

218
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

With indication type, one object address (OA) contains 16

bits and it includes both single and double indications.

Allocation

This item specifies whether the topic is in use or not. The memory needed for the topic
is reserved, when the topic is taken into use. Values: Enabled or disabled.

First Object Address

First Object Address specifies the first object address used with this topic. Object address
and object type parameters specify together the actual process object address (OA),
where the first item in the topic is stored. Values: 1 … 4096.

Last Object Address

Last Object Address refers to the object address of the last item of topic. Values: 1 …
4096. The number of items reserved by the topic is calculated in the following way:

• Number of items = Last object address - First object address

Base Address

Base Address specifies the address of first item of topic in the device's memory. Values:
0 … 65535.

Format

Format specifies how the data is stored in an external device.

Interval

Interval specifies the frequency that the data of topic is read from an external device.
The interval units are milliseconds. If the interval is 0, the topic is not polled. Values: 0
… 65535.

219
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

Deadband

If the type of topic is an analog value, then the Deadband value is used to minimize the
amount of updating messages from the PC-NET to the base system. The new analog
value is sent to the base system, when the change or sum (integral) of changes is bigger
than the deadband. Values: 0 … 65535.

5.4.17.4. Configuring data points for DNP stations

DNP V3.00 protocol provides versatile possibilities for data polling. In DNP V3.00, the
data polling can be configured in a different way in each DNP V3.00 master device. The
data polling for DNP master station is defined in the Advanced page of the System
Configuration Tool, as shown in Figure 5.4.17.4-1.

A060304

Figure 5.4.17.4-1 The data point configuration of DNP station in the Advanced page of the System
Configuration Tool

To add a new item, click the Add button. This action opens the Add Data Point Item
dialog. In this dialog, the default type is event poll. If the DNP station already contains
the defined event poll item, the default type is always freely defined poll. If DNP station
already includes the maximum number of data point items, the Add button is disabled,
as there may be maximum fifty freely defined data point items for one DNP device.

To delete the existing data point items, select the appropriate item in the list and click
Delete. Before the delete operation is done, a notification dialog is displayed to the user.
Click Yes to delete the selected data point item and refreshes the list. Click No to cancel
the deletion.

220
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

To edit the existing data point item, select the appropriate item in the list and click Edit
or double-click the data point item. The selected items are displayed in the Data Point
Configuration Editor with the existing definitions, as shown in Figure 5.4.17.4-2. In this
dialog, the poll type, polling interval, object, variation, description, number of events
and lower/upper limit of index range are defined.

A060306

Figure 5.4.17.4-2 Editing the existing data point item

Poll Type

Pole Type specifies the poll type of a data point item. There may be one event poll and
maximum 50 freely defined polls for a DNP station.

Polling Interval

Polling Interval specifies the polling interval as seconds. Setting this parameter to zero
stops the poll, which is the default for freely defined poll. For event poll, the default is
100.

Description, Object and Variation

This is a combination of Object and Variation specifies the information element structure
for a data point item. It is also possible to select the information element structure directly
from the Description list. In both cases, only the relevant Object and Variations appear
in the lists.

Number of Events

Number of Events specifies the number of events to be polled. Value 0 indicates that all
events are to be polled. Default value is 0.

221
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

Lower Limit of Index Range

Lower Limit of Index Range specifies the lower limit of the index range. If 0, all data
points with the given data object type and variation are polled. Default value is 0.

Upper Limit of Index Range

Upper Limit of Index Range specifies the upper limit of the index range. If 0, all data
points with the given data object type and variation are polled. Default value is 0.

All the above definitions are applicable to the freely defined poll, except the Number of
Events definition. For an event poll, only the Polling Interval and Number of Events are
applicable.

5.4.17.5. Configuring memory areas for STA stations

For STA stations the memory area configuration for data items is defined in the Advanced
page, as shown in Figure 5.4.17.5-1.

A060301

Figure 5.4.17.5-1 The memory area configuration of STA station in the Advanced page of the
System Configuration Tool

To add a new item, click the Add button, which opens the Add Memory Area Item
dialog as shown in Figure 5.4.17.5-2. In this dialog, the default type is binary input or
the type of the last added item. If STA station already includes 30 items, the Add button
is disabled, as the maximum number of the memory area items for each STA device is
30.

222
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

A060302

Figure 5.4.17.5-2 New memory area item, Binary Input, is added to the STA station

To delete the existing memory area items, select the appropriate item in the list and click
Delete. Before the deletion is done, a notification dialog is displayed to the user. Click
Yes to delete the selected memory area item and refreshes the list. Click No cancel the
delete operation.

To edit the existing memory area item select the appropriate item in the list and click
Edit or double-click the memory area item. The selected items are displayed in the
Memory Area Configuration Editor with the existing definitions, as shown in Fig-
ure 5.4.17.5-3. In this dialog, the data type, coding, start address, length, access type,
block format, time stamp and split destination are defined.

A060303

Figure 5.4.17.5-3 Editing the existing memory area item

223
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

Data Type

Data Type specifies the data type of process objects. The following data types of STA
device are available: Binary Input, Binary Output, Analog Input, Analog Output,
Transparent and Time Sync Data.

Coding

Coding specifies the coding of the data elements in the address interval defined by the
memory area. The value of CO attribute tells the communication program how to interpret
the data of the memory area.

Values:

1 - 8 Bit Binary Value

2 - 12 Bit Binary Value

3 - 16 Bit Binary Value

4 - 32 Bit Binary Value

5 - 3 Digit BCD Value

6 - 4 Digit BCD Value

7 - Not in Use

8 - Not in Use

9 - 32 Bit Floating Point Value

10 - ASCII Data

11 - 16 Bit Integer Value

12 - 32 Bit Integer Value

Start Address

Start Address specifies the word address of the first word’s memory area. Value range:
0 - 32767.

Length

Length specifies the number of words in the memory area. Value range: 0 - 32767.

224
1MRS756646 MicroSCADA Pro SYS 600 9.3

System Configuration

Access Type

Access Type defines whether the write commands directed to this memory area are
protected or unprotected. The attribute is relevant only to Allen Bradley stations. Values:

0 = Unprotected

1 = Protected

Block Format

Block Format states if the spontaneous command messages from the station use the basic
format of the protocol, or if an additional address field is used. Values:

1 = Basic Allen-Bradley

2 = Special 1 (the message contains a second word address, which is a BCD coded octal
number)

3 = Special 2 (the message contains a second, binary word address)

4 = Multi-Event Transmission (allows transmission of many events with non-continuous

addresses in the same telegram)

Time Stamp

Time Stamp states whether the time tagged information is included in spontaneous
commands from the station. Values:

0 = No Time Stamp

1 = Time Stamp

Message Split Destination List

Message Split Destination List defines the applications that will receive the message.
Receiving applications can only be defined if Message Split attribute of station is defined
(SP > 0).

5.5. Base System Object Navigator

The Base System Object Navigator tool is an online tool that provides the following
common functionality:

225
SYS 600 9.3 MicroSCADA Pro 1MRS756646

System Configuration

• Recognizing of the base system objects in SYS 600 system

• Viewing of the base system related attributes and their values
• Editing of the base system object related attribute values
• Adding of base system objects

For further information about Base System Object Navigator, see SYS 600 System
Objects.

As the tool is an online tool, the modified attribute values or added base system objects
affect only the running system. If there is need to configure the system permanently, the
changes should be made to base system configuration files (SYS_BASCON.COM).

5.6. Communication Engineering tool

MicroSCADA Pro SYS 600 includes Communication Engineering tool for IEC 61850
OPC Server. This tool is used for the configuration tasks before you can start using the
IEC 61850 OPC Server in your system.

5.6.1. Building an object tree

The building of an object tree is possible by using Project Explorer of CET, and the
purpose is to create the hierarchical communication structure for the project. The required
steps, when using Project Explorer in CET has been described in the MicroSCADA Pro
IEC 61850 Master Protocol manual.

5.6.2. Configuring objects

For each object found in the object tree, there are set of properties that can be adjusted
by using Object Properties of CET. In this way, the communication details, such as IP
Address of the Communication Port for IEC61850 Subnetwork can be set. See SYS 600
IEC 61850 Master Protocol (OPC) for further details of configuring object properties.

5.6.3. Using object tools

When some object is selected in the object tree, the applicable object tools can be found
from the Tools menu and object tree's Context menu. These tools are used, when
building the object tree or later on, when performing operations with these objects.
Examples of such a tools are: SCL Import, Management and Online Diagnostics. For
further details of using these tools, see SYS 600 IEC 61850 Master Protocol (OPC).

Usage of Connectivity Packages for protection and control products increases the con-
figuration efficiency in object tree. Due to this reason, it is important to understand which
Connectivity Packages should be installed into the IEC 61850 system.

226
Contact us

1MRS756646 B/31.12.2010 © Copyright 2010 ABB. All rights reserved.

ABB Oy
Substation Automation Products
P.O. Box 699
FI-65101 VAASA, FINLAND
Tel. +358 10 22 11
Fax. +358 10 224 1094

www.abb.com/substationautomation