SYS600 System Configuration

MicroSCADA Pro
SYS 600 *9.1

System Configuration
Configuration Manual
1MRS751846-MEN MicroSCADA Pro SYS 600 *9.1
Issued: 26.03.2003 System Configuration
Version: E/18.03.2005
1. About this manual .....................................................................7

1.1. Copyrights .....................................................................................7
1.2. Trademarks ...................................................................................7
1.3. General .........................................................................................7
1.4. Document revisions .......................................................................8
2. Introduction ...............................................................................9
2.1. System description ........................................................................9
2.2. Configuration principles ...............................................................14
3. Base system object definitions .............................................17
3.1. Overview .....................................................................................17
3.2. Configuration files .......................................................................18
4. Communication system object definitions ...........................27
4.1. Overview .....................................................................................27
4.2. Defining communication system objects off-line .........................28
4.3. Defining communication system objects on-line .........................29
5. Configuration data files ..........................................................35
5.1. General rules ...............................................................................35
5.2. Frontend configuration parameters .............................................36
6. Base systems ..........................................................................41
6.1. Configuring a base system ..........................................................41
6.2. Communicating applications .......................................................45
7. MicroSCADA networks ...........................................................51
7.1. Global definitions .........................................................................51
7.2. Object numbering ........................................................................53
8. Local area networks (LANs) ...................................................55
9. Process communication system ...........................................57
9.1. Configuring a communication unit (NET) ....................................57
9.2. Internal NETs (DCP-NETs) .........................................................61
9.3. Configuring base systems with PC-NET .....................................63
9.4. Communication frontends ...........................................................65
9.5. Networks of interconnected NETs ...............................................69
10.Operator workstations ...........................................................77
11.Peripherals ..............................................................................79
11.1.Printers .......................................................................................79
11.2.Other peripherals ........................................................................85
12.Configuring stations ..............................................................87
12.1.General principles .......................................................................87
©Copyright 2005 ABB Oy, Substation Automation Products, Vaasa, FINLAND 3

SYS 600 *9.1 MicroSCADA Pro 1MRS751846-MEN
12.2.Stations using ANSI X3.28 protocol ........................................... 89

12.2.1.MicroSCADA configuration .............................................. 89
12.2.2.SRIO configuration .......................................................... 96
12.3.S.P.I.D.E.R. and Collector RTUs ............................................... 99
12.3.1.MicroSCADA configuration .............................................. 99
12.3.2.RTU configuration .......................................................... 102
12.4.Stations in the LONWORKS network ....................................... 102
13.Mirroring ............................................................................... 105
13.1.Functional overview ................................................................. 105
13.2.Technical overview ................................................................... 105
13.3.Configuration ............................................................................ 114
13.3.1.Example 1. One host, one image .................................. 115
13.3.2.Example 2. Two hosts, redundant image ...................... 117
13.3.3.Example 3. Station mapping in a mirroring system ....... 119
13.3.4.Example 4. Local mirroring ............................................ 121
13.3.5.Example 5. Hierarchical mirroring .................................. 122
14.Redundancy configurations ............................................... 125
14.1.Hot stand-by base systems ...................................................... 125
14.1.1.Base system configuration procedure ........................... 127
14.1.2.Editing SYS_BASCON.HSB .......................................... 127
14.1.3.NET configuration .......................................................... 135
14.1.4.Installing watchdog application ...................................... 135
14.1.5.Starting the shadowing .................................................. 136
14.1.6.Editing the command procedures .................................. 136
14.1.7.An example hot stand-by configuration ......................... 139
14.2.Redundant frontends ................................................................ 144
14.3.Communication loops ............................................................... 151
14.4.Hot stand-by with OPC client and servers ............................... 154
15.Miscellaneous ...................................................................... 161
15.1.System message handling ....................................................... 161
15.2.Auto-dialling ............................................................................. 164
15.3.Time synchronization ............................................................... 166
15.4.Storing the event history .......................................................... 168
15.4.1.History database ............................................................ 168
15.4.2.Event log ........................................................................ 169
16.System Configuration Tool ................................................. 171
16.1.Main functions .......................................................................... 171
16.2.Starting the tool ........................................................................ 172
16.3.How to handle the object and attribute trees ............................ 172
16.4.How to save a configuration from a former release ................. 173
16.5.How to create a new configuration ........................................... 173
4
16.5.1.Methods for adding new objects ....................................174

16.5.2.Adding a redundant line .................................................175
16.6.Default configuration .................................................................176
16.7.On-line configuration ................................................................177
16.8.How to change the attribute values ..........................................179
16.8.1.NET Node Station address ............................................180
16.9.How to take a configuration in use or out of use ......................180
16.10.How to delete an object ..........................................................182
16.10.1.How to delete a redundant line ....................................182
16.11.Cut, copy and paste functions; reallocating stations ..............182
16.12.Preview function .....................................................................184
16.13.User-defined programs ...........................................................184
16.14.General object handling command .........................................186
16.15.Environment ...........................................................................187
16.16.System Self Supervision with Monitor Classic ........................187
16.17.System Self Supervision with Monitor Pro ..............................190
16.17.1.Supervision Application Objects ...................................191
16.17.2.Supervision Monitoring .................................................192
16.17.2.1.Proposed SA symbols ....................................192
16.17.2.2.Dynamics .......................................................193
16.17.2.3.Base System Supervision ..............................197
16.17.2.4.Monitor Classic Supervision ...........................198
16.17.2.5.Communication ..............................................199
16.17.2.6.Communication Line ......................................200
16.17.2.7.Station ............................................................201
16.17.2.8.LON Clock Master ..........................................202
16.18.Signal engineering ..................................................................203
16.18.1.Signal engineering on station level ..............................203
17.NETCONF Tool .....................................................................187
17.1.Requirements ...........................................................................187
17.2.Installation ................................................................................187
17.3.NETCONF tool basics ..............................................................187
17.4.Using NETCONF Tool ..............................................................190
18.NET Tool ................................................................................197
18.1.NET Tool basics .......................................................................197
18.2.Using the NET PRECONFIGURATION Tool ............................199
19.REx Configuration Tool .......................................................205
19.1.Using REx Configuration Tool ..................................................205
19.2.Defining the device ...................................................................207
20.LMK Configuration Tool ......................................................211
5
20.1.Using LMK Configuration Tool ................................................. 211
20.1.1.Defining the device ........................................................ 214
21.Index ..................................................................................... 217
1. About this manual
1.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
permission 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 © 2005 ABB Oy
All rights reserved.
1.2. Trademarks
Registrations and trademarks used in this document include:
Windows: Registered trademark of Microsoft Corporation.
LonWorks: Registered trademark of Echelon Corporation Inc.
1.3. General
This manual gives you information on the various configuration settings that you
have to make in order to take your MicroSCADA system in use. It also describes
how to use the configuration tools, which are available in the current release.
7
1.4. Document revisions
Version Revision number Date History

A 8.4.4 15.03.2004 Document created
B 8.4.4 26.03.2004 SYS_CONFIG.PAR and SYS_BASCON.COM
updated in Chapter 2
Chapter 12, Mirroring added
C 8.4.5 15.01.2004 Internal mirroring and hierarchical mirroring
added in Chapter 12
Adding a redundant line added in Chapter 15
Windows NT changed to Windows
D 9.0 30.06.2004 Document updated
E 9.1 18.03.2005 Additions, System Self Supervision and HSB
features
8
2. Introduction
This chapter introduces the MicroSCADA system concepts and the system
configuration principles:
2.1 The first section provides a summary of the MicroSCADA system with
emphasis on the concepts which are central when configuring
MicroSCADA: the base systems, the process data communication
system, the connection of devices to a distributed network, etc.
2.2 The MicroSCADA configuration principles: the MicroSCADA
configuration software modules and the configuration software
management.
2.1. System description

A MicroSCADA system is composed of one or more base systems, a process
communication system, workstations and peripherals. In addition, it may utilise
local area networks (LANs). See Figure 2.1.-1.
Base systems
The MicroSCADA base systems are control centres that contain the supervisory
control and monitoring functions of MicroSCADA. The tasks of a base system are
to collect all process-related data from the stations into the process database,
distribute the information and to send control commands via the NET
communication units.
Each base system is composed of a base system computer including base system
software. The base system computer is a standard PC running the Windows
operating system. The MicroSCADA base system software comprises the
MicroSCADA kernel, a number of facility programs, engineering and system
handling tools, configuration software and application software.
The MicroSCADA kernel, as well as most of the engineering and system handling
tools, is the same in all base systems independently of the application area and the
extent of use.
The configuration software is specified for the base system in question and adapted
to the device configuration of the entire MicroSCADA system.
A base system may contain one or more applications. An application includes
application software and databases. The application software specifies the functions
of the MicroSCADA base system as a supervisory control system. The application
software is adapted for a certain process and for the user’s needs regarding the level
of information, user interface, control operations, and so on. A base system can run
several applications in parallel.
Process communication system

The process communication system connects the application software in the base
systems with the process stations which gather process data, and performs the
control commands. In addition, it may interconnect several base systems, as well as
base systems and printers.
9
The process communication is handled by a number of parallel or serially

interconnected communication units, also called NETs. A NET is a communication
program running on a special communication board (board based NETs or DCP
NETs) or directly on the CPU of a PC (PC based NETs or PC NETs). The NETs may
be situated within the base system computers and within PCs specially assigned for
process communication. Such PCs are called frontends or communication frontends.
LANs
LANs may be used for connecting base systems with other base systems, base
systems with frontends, and base systems with workstations.
10
MicroSCADA System Overview

PCs containing workstation programs
Operator
Workstations
Local Area
Network (LAN)
Operator workstation Printers Alarm unit
Base System computer

Base System Software Application Software
- Kernel (main program) - Pictures, dialogs
- Engineering tools - Report data
Base Systems - Base System Configuration - Process data
- Application software - Control programs, etc.
and
Peripherals
DCP-NET units:
- Communication card - NET program
- Communication program - Configuration file
incl. conf parameters
Process
Communication
System Communication frontends
- Communication card
- Communication program
incl. conf parameters
System_overview.eps
Fig. 2.1.-1 The main system components of MicroSCADA
Workstations
A MicroSCADA workstation is a PC that runs the MicroSCADA HSI (Human
System Interface). To be able to run the HSI, the workstation must run an X Server
program.
11
The workstations are connected via LAN or via remote connections, which use the
operating system feature RAS.
Peripherals
The printers are connected to the base system computers, to a LAN via printer
servers, or to the process communication system.
External alarm units can be connected to the base systems.
Radio clocks for external clock synchronization may be connected to the base
systems, to NETs, and to the frontends.
MicroSCADA networks
Figure 2.1.-2 shows an example of a MicroSCADA system. The system can be
regarded as a network where the communication units (NETs) and the base systems
function as routing nodes, which can forward messages and data from one node or
device to another. All base systems connected by the same process communication
system or by a LAN belong to the same network.
There may be several communication units in a series between two communicating
devices. However, for performance reasons, it is not recommended to have more
than three communication units between communicating devices. In a large
network, the routes between nodes can be doubled to obtain redundancy.
12
Fig. 2.1.-2 An example of a MicroSCADA network. Most configuration

possibilities are represented in this network, which will be used as an
example throughout this manual.
Interoperability
An essential feature of MicroSCADA is the interoperability between separate base
systems. Interoperability means that all the connected applications can
communicate, if they are situated in the same base system or in separate base
systems. In Figure 2.1.-2, for instance, all applications can intercommunicate.
Communication between the base systems 2 and 3 requires some special
arrangements in base system 1.
The connected devices - printers, workstations and process units - can be shared by
several base systems in the network. The workstations connected to a LAN, for
example, can be used by all base systems connected to the same LAN. Likewise, the
13
stations and printers connected to NETs can be used by all base systems connected
to the same network of interconnected NETs. A frontend can recognise up to four
base systems.
In the network of Figure 2.1.-2, for example, all the applications in base systems 1
and 3 can utilise the workstations on the LAN. The PCs running X software can be
connected to several base systems and applications simultaneously. Application 5
can use both printers 1 and 2. A redirection of printout can be done during operation.
2.2. Configuration principles

For a MicroSCADA system to operate properly, it must be configured for the
special environment in which it is operating. MicroSCADA contains configuration
software in the form of objects and data files. The configuration software defines:
• Nodes
• Applications
• Device connections
• Communication properties
• Memory capacities, destination addresses, etc.
The System Configuration Tool manages the configuration of the base system and
the PC-NET. In the current version, the following base system and system objects
can be created and configured:
• Integrated link to the PC-NET
• PC-NET
• LonTalk (LON), IEC, RP 570, RP 571, LCU500, DNP 3.0, Modbus and SPA
protocol Lines
• REX, LMK, IEC, SPI, LCU500, DNP, PLC, and SPA Stations
• LON Clock Master and LON Star Coupler
Configuration software
The MicroSCADA configuration software is composed of objects and data that
reside in the base systems, communication units (NETs) and communication
frontends, see Figure 2.2.-1:
• 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
reside in the primary memory of the base system computer. The base system
objects are created with SCIL commands, when the MicroSCADA base system is
started. They can be added and modified during the operation.
• Each communication unit contains a set of system objects that specify the unit
itself and its environment. During the operation, the system objects reside in the
memory of the communication boards (DCP-NETs) or PC (PC-NETs). The NET
programs contain a preconfiguration, which gives the system objects default
values. The system objects can be added and modified during the system
operation.
• The communication frontends contain data files, which specify the frontend
configuration and the parameters for the communication with the base system.
14
The process units (stations) contain their own configuration definitions that must be
regarded in the MicroSCADA configuration. For some station types, the
configuration can be built in MicroSCADA and downloaded to the stations.
The MicroSCADA configuration software handling is detailed in Chapter 2 of this
manual.
Building system configuration

As a rule, when a device is added to the MicroSCADA system, several
configuration modules are affected. For example, when a process unit (station) is
connected to a NET, additions and modifications are required in:
• The base system which will use it: base system objects
• The communication unit to which it is directly connected: system objects
Concerning PC-NET and LONWORKS network, the configuration work is done with
the System Configuration Tool. It automatically gives default values which can be
changed, if needed.
The MicroSCADA system configuration can be changed any time. However, in
some cases a shut-down and restart is required for the changes to become valid.
15
Fig. 2.2.-1 The configuration software modules in MicroSCADA

The communication server COM 500 is described in the COM 500 Engineering
Manual.
16
3. Base system object definitions

This chapter describes the definition of the base system objects. It contains the
following two sections:
3.1 An overview of the base system objects and the alternatives for
defining base system objects.
3.2 A description of configuration files SYS_CONFIG.PAR,
SYS_BASCON.COM and NET_BASCON.COM. These files define
the initial configuration of the base system during the MicroSCADA
start-up.
The base system objects and their attributes are detailed in the System Objects
manual.
3.1. Overview
Base system objects

Each base system has a set of base system objects which specify the base system
and its environment, the hardware and software of the base system, the physical
and logical connections of the base system and its applications. A base system is
completely configured by the following base system objects:
• A SYS object for the base system itself.
• An APL object for each application residing in the base system ("local
applications") and an APL object for each communicating application residing in
connected base systems ("external applications").
• A MON object for each MicroSCADA monitor that will be opened to supervise
an application in the base system.
• A LIN object for each connection link. A LIN object is neither needed for
peripherals, nor for workstations.
• A NOD object for each directly or indirectly connected base system and NET
unit (optionally also for each communication frontend).
• A PRI object for each printer, including both real printers and pseudo-printers for
sending the printout to files, which will be used by the base system.
• A STA object for each connected station (connected through one or more NETs)
(recommended in all cases, though not always required).
The base system object definitions and attributes, which are required for various
installations, are detailed later in this manual.
Principles for defining base system objects

Generally, the base system objects are defined in the SYS_BASCON.COM file. The
file is read and the commands in it are executed each time the base system is started.
With a few limitations, the base system objects can also be created and modified
during the MicroSCADA operation with SCIL and tool pictures.
Base system objects are created using the SCIL command #CREATE. The
principles for creating a base system object with SCIL are as follows:
#CREATE object = LIST(attribute = value, attribute = value,...)
17
‘object’ The object to be created is specified using the base system object
notation without attributes and index numbers
‘attribute’ Attribute name
‘value’ The value assigned to the attribute
Example:
Creating a SYS object:
#CREATE SYS:B = LIST(-
SA = 209,- ;STATION ADDRESS OF THE BASE SYSTEM
ND = 9,- ;NODE NUMBER OF THE BASE SYSTEM
DN = 1,- ;DEFAULT NET NODE NUMBER
DS = "RTU",- ;STA TYPES: E.G. STA,RTU,SPA,REX
FS = "NEVER") ;FILE SYNCH CRITERIA
After a base system object has been created, its attributes (provided that writing is
enabled) can be changed with the #SET command. The objects cannot be modified
with the #MODIFY command nor can they be deleted with the #DELETE
command.
To learn more about the SCIL commands, refer to the Programming Language SCIL
manual, Chapter 7. For more information on the base system object notation, refer
to the System Objects manual, Chapter 2.
On-line modifications
Most base system object attributes can be modified on-line with the Base System
tool and with SCIL. These changes are not persistent and will be lost when the
system is shut down. If the changes are to be persistent, they should be included in
the SYS_BASCON.COM file.
3.2. Configuration files

When the MicroSCADA program starts up, it reads the following four
configuration files to set up its initial configuration:
• SYS_CONFIG.PAR contains parameter values that configure the program itself.
These parameters may not be set by SCIL.
• SYS_TIME.PAR contains the history of the time zone and daylight saving time
rules of the site. This file should not be modified by the user. See the
Programming Language SCIL manual for details (function
TIME_ZONE_RULES).
• SYS_BASCON.COM contains a SCIL program that creates the base system
objects.
• SYS_NETCON.COM contains a SCIL program that loads the DCP-NET
program(s) used by the system. Because DCP-NETs are seldom used any more,
this file is normally not required, or it may be empty.
All these files are located in the directory \msroot\sys\active\sys_, where msroot
stands for the root directory of the MicroSCADA installation, normally ‘sc’.
If the System Configuration tool is used, the station (STA) objects

are not defined in SYS_BASCON.COM. Their configuration is
managed by the tool, see Chapter 15 .
18
SYS_CONFIG.PAR
The configuration file SYS_CONFIG.PAR is a text file containing settings of
system parameters that cannot be set with SCIL. The file is read at system start-up
before the execution of SYS_BASCON.COM. SYS_CONFIG.PAR can be edited
with a text editor.
SYS_CONFIG.PAR can contain the following parameters and set values:
MEMORY_POOL_SIZE
specifies the size of the global memory pool in megabytes (MB). Possible values
are: 4, 8, 12, 16, 20, 24,...., that is a value divisible with 4. Default, if no value is
given in SYS_CONFIG.PAR, is 64 MB. For example the line:
MEMORY_POOL_SIZE = 100
sets the size of the global memory pool to 100 MB.

MEMORY_POOL_ADDRESS
specifies the start virtual address of the global memory pool. The start address
(default value 30000000) should be changed (by trial and error or examining the
DrWatson log) to a new value if the start of a monitor or an external program
(Application Extension Program or Integrated Program) fails and the message “?
Map_Global_Memory (MapViewOfFileEx): 487” is shown in the Notification
Window. The address is given as an 8-digit hexadecimal number with 6 trailing
zeroes. Any value between 20000000 and 6F000000 may be tried. A good value will
be found quickly, if sequence 20000000, 28000000, 30000000 etc. is used. When a
valid value is found, it may be used in all MicroSCADA installations running the
same external programs and the same operating system configuration. The value
does not depend on MicroSCADA configuration, such as number of monitors or
network connections etc.
The parameter MEMORY_POOL_HOLE offers an alternative (and recommended)
way of finding a valid memory pool address. It is easier to use, because the
MicroSCADA program does the trial-and-error procedure.
MEMORY_POOL_HOLE
This parameter advises the MicroSCADA start-up 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 a monitor process or 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.
The parameter MEMORY_POOL_ADDRESS should not be touched. After the
restart the program should initialize without errors. The configuration file may
contain several MEMORY_POOL_HOLE lines, because there is a slight possibility
that even the second start-up fails now suggesting another hole in the pool address
space.
PICO_MEMORY_POOL_SIZE
REPR_MEMORY_POOL_SIZE
19
PRIN_MEMORY_POOL_SIZE
These three parameters define the sizes of the local memory pools of
MicroSCADA processes:
PICO_MEMORY_POOL_SIZEDetermines the size (as megabytes) of the local
memory pool of all the monitor processes in the
system. The default value is 16 MB.
REPR_MEMORY_POOL_SIZEDetermines the size of the local memory pool of all
repr processes. The default value is 8 MB.
PRIN_MEMORY_POOL_SIZEDetermines the size of the local memory pool of all
prin processes. The default value is 4 MB.
Setting a pool size to 0 demands the processes of the category to always use the
global memory pool.
If a process requires more memory than the specified memory pool size allows the
dialog "SCIL Application Error/Memory Pool Exhausted" is shown. The dialog
shows a critical error with information about which pool caused the error. The
information is either "Local memory pool exhausted" or "Global memory pool
exhausted".
ANALOG_SWITCH_STATE_CLOSED (default = 1)
ANALOG_SWITCH_STATE_OPEN (default = 2)
ANALOG_SWITCH_STATE_MIDDLE (default = 0)
These parameters define the translation of the CLOSED, OPEN and MIDDLE states
returned by the program interface function SCIL_Get_Switch_State.
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 the System Base Software package. The contents of the
SYS_CONFIG$PAR is:
; File: Sys_config.par
; Description: Configuration for ’static’ base system parameters
; leading ’;’ indicates commented line
; Version 9.0
;---------------------------------------------------------------
;
;MEMORY_POOL_ADDRESS = 30000000 ;Memory pool start address
;MEMORY_POOL_SIZE = 64 ;Must be 4,8,12,16,20,24,28,... (MB)
;PICO_MEMORY_POOL_SIZE = 16 ;Memory Pool for Monitor processes
;REPR_MEMORY_POOL_SIZE = 8 ;Memory Pool for Report processes
;PRIN_MEMORY_POOL_SIZE = 4 ;Memory pool for Printer processes
;
;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
SYS_BASCON.COM
The system configuration of the MicroSCADA base system is defined in the
SYS_BASCON.COM configuration file.The file is a text file containing SCIL
statements for creating the base system (B) objects. The System Base software
package contains two SYS_BASCON.COM template files, one for configuring a
single base system and one for configuring a hot-stand-by base system. The template
20
file for a single base system, SYS_BASCON$COM, is during installation copied to

SYS_BASCON.COM if the SYS_BASCON.COM does not previously exist. The
template file for hot-stand-by systems is called SYS_BASCON.HSB.
The SYS_BASCON$COM template file defines a system configuration as
presented in Figure 3.2.-1. The configuration consists of an application called
“TUTOR”. Two PRI objects, one “normal” and one “transparent”, are connected to
the Windows printer manager. Both objects correspond to one physical printer. A
third PRI object is connected to a NET node. The fourth PRI object, PRI15, is
defined as a log printer printing to a specified log file. The base system has four
communication links to NET nodes. Two of the NET nodes are running on internal
DCP-NET cards. One node is connected to the TCP/IP LAN link and one node,
which is running the PC-NET communication software is connected over an
integrated link to the base system. The configuration allows ten MicroSCADA
monitors to be opened to the TUTOR-application.
Fig. 3.2.-1 The system configuration defined by the delivered configuration software
Also the other configuration files included in the delivery (NET_BASCON.COM,
the DCP-NET preconfiguration, PC_NET.CF1 and PC_NET.COM) conform with
the configuration in Figure 3.2.-1.
21
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 #CREATE command that creates the base
system object.
To edit the current SYS_BASCON.COM:
1. Open the MicroSCADA Control Panel.
2. Click Admin.
3. Click Config.
The SYS_BASCON.COM file is opened in the Notepad program for editing.
;File: Sys_bascon.com
;Desription: Standard Base system configuration file
; Version 9.0
;----------------------------------------------------
;----------------------------------------------------
;Base System Object
@l_Standard_Paths = do(read_text("/STool/Def/Path_Def.txt"))
#CREATE SYS:B = List(-

SA = 209,- ;Station address of base system
ND = 9,- ;Node number of base system
TM = "SYS",- ;Time Master, SYS or APL
TR = "LOCAL",- ;Time Reference, LOCAL or UTC
DN = 1,- ;Default NET node number
DS = "STA",- ;Default STA type: E.G. STA,RTU,SPA,REX
DE = 0,- ;DDE server 0=disabled, 1=enabled
OP = 1,- ;OPC server 0=disabled, 1=enabled
PC = 6000,- ;Picture Cache (kB)
RC = 1000,- ;Report Cache (kB)
-
- ;MS-STOOL Settings
PH = %l_Standard_Paths,-
SV = (0,- ;System Variables
list(t_System_Configuration_File = "sys_/SysConf.ini",- ;System
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 = "8.4.3")),-
- ;Operating System events
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,
Bit_Mask(0,1,2,3,4)),- ;Security events (Bit 0=ERROR, 1=WARNING,
-
FS = "NEVER") ;File sync. criteria:
NEVER,MAINT,SET,CHECKPOINT,ALWAYS
;----------------------------------------------------
;Communication Links
;NOTE! Use the system configuration tool to create a link for the PC-NET!
#CREATE LIN:V = LIST(- ;Link to DCP-NET (requires DCP driver)

LT = "RAM",- ;Link type
22
SD = "RM00",- ;DCP card (first:RM00, second RM01)

RE = "BCC",- ;Redundancy
TI = 2,- ;Timeout length (s)
NA = 3,- ;NAK limit
EN = 3) ;ENQ limit
;#CREATE LIN1:B = %LIN
#CREATE LIN:V = LIST(- ;Link to other SYS or LAN frontend (requires

TCP/IP)
LT = "LAN") ;Link type
;#CREATE LIN2:B = %LIN
;----------------------------------------------------
;Node objects (NET’s and SYS’s)
;NOTE! Use the system configuration tool to create nodes for the PC-NET!
#CREATE NOD:V = LIST(- ;Node for DCP-NET

LI = 1,- ;Link number
SA = 201) ;Station address: 0..255
;#CREATE NOD1:B = %NOD
#CREATE NOD:V = LIST(- ;Node for LAN frontend or SYS

LI = 2,-
SA = 202)
;#CREATE NOD2:B = %NOD
;----------------------------------------------------
;Printers
;#do Read_Text("sys_/pr_default.dat") ;This line is needed for the

transparent printer below
;#CREATE PRI:V = LIST(- ;Transparent type printer
; TT = "LOCAL",- ;Translation type
; DT = "TRANSPARENT",- ;Device type
; OJ = 1,- ;Printer opened on job basis
; DC = "LINE",- ;Device connection: CONSOLE, LINE OR NET
; CS = %CS,- ;Control sequences
; SD = "\\My_NT\My_Printer",- ;System device name
; LP = 66) ;Lines per page
;#CREATE PRI1:B = %PRI
#CREATE PRI:V = LIST(-

TT = "LOCAL",-
DT = "NORMAL",-
DC = "LINE",-
SD = "\\My_NT\My_Printer",-
LP = 66)
#CREATE PRI:V = LIST(-

TT = "LOCAL",-
DT = "COLOR",-
DC = "NET",-
ND = 4,- ;NET node number: 1..99
TN = 1,- ;Translated object number (printer nr in net)
LP = 66)
;#CREATE PRI:V = LIST(- ;Required if HP of application is

"EVENT_LOG" (History logging Policy)
; TT = "LOCAL",-
; OD = "LOG",- ;Output destination (LOG, PRINTER)
; LL = "DAY",- ;Log Length (DAY, WEEK, MONTH)
; LD = "/APL/TUTOR/PICT",- ;Log directory
; LP = 0)
23
;----------------------------------------------------
;Monitors
#LOOP_WITH I = 1..5
#Create MON’I’:B = LIST(-
TT = "LOCAL",- ;Translation type
DT = "VS") ;Visual SCIL monitor
@MON_MAP(%I) = -1
#LOOP_END
#LOOP_WITH I = 6..10
#CREATE MON’I’:B = LIST(-
TT = "LOCAL",- ;Translation type
DT = "X") ;X monitor
@MON_MAP(%I) = -1
#LOOP_END
;----------------------------------------------------
;Applications
;The usage of OI & OX -attributes (required by LIB 500)

@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)))
;Create Application specific global paths

@l_Global_Paths = list()
;Add LIB5xx global paths to list if LIB5xx installed

@t_LIB_Path_Def_File = "/LIB4/Base/Bbone/Use/Bgu_Glpath.txt"
#if File_Manager("EXISTS", Fm_Scil_File(%t_LIB_Path_Def_File)) #then #block
#error continue
@v_File_Contents = read_text(%t_LIB_Path_Def_File)
#if substr(%v_File_Contents(1),5,16) == "LIB 500 revision" and
substr(%v_File_Contents(1),22,5) >= "4.0.2" #then #block
#modify l_Global_Paths:v = do(read_text(%t_LIB_Path_Def_File))
#block_end
#error stop
#block_end
#if substr(SYS:BPR, 1, 7) == "SYS_600" #then #block ; PP
;Add SA_LIB global paths to list

@t_SALIB_Path_Def_File = "/SA_LIB/Base/Bbone/Use/Bgu_Glpath.txt"
#if File_Manager("EXISTS", Fm_Scil_File(%t_SALIB_Path_Def_File)) #then
#block
24
#error continue
@v_File_Contents = read_text(%t_SALIB_Path_Def_File)
#if substr(%v_File_Contents(1),5,14) == "SA LIB version" and
substr(%v_File_Contents(1),20,5) >= "1.0.0" #then #block
#modify l_Global_Paths:v = do(read_text(%t_sALIB_Path_Def_File))
#block_end
#error stop
#block_end
#block_end
#CREATE APL:V = LIST(-

TT = "LOCAL",- ;Translation Type
NA = "TUTOR",- ;Name of application directory
AS = "HOT",- ;Application state (COLD,WARM,HOT)
PH = %l_Global_Paths,-
-; PQ = 15,- ;Number of parallel queues/ Needed
in COM500 Applications
-; QD = (1,1,0,0,0,0,1,1,1,1,1,1,1,1,1),- ;Parallel queue dedication/
Needed in COM500 Applications
SV = %SV,- ;System variable (RESERVED)
CP = "SHARED",- ;Color Allocation Policy
-; RC = VECTOR("FILE_FUNCTIONS_CREATE_DIRECTORIES"),- ;Revision
compatibility
HP = "DATABASE",- ;History Logging Policy ("DATABASE", "EVENT_LOG",
"NONE")
EE = 1,- ;System Events & Operating System Events (1=Enabled,
0=Disabled)
AA = 1,- ;Number of APL-APL servers
MO = %MON_MAP,- ;Monitor mapping
PR = (1,2,3)) ;Printer mapping
#CREATE APL1:B = %APL
;#CREATE APL:V = LIST(- ;LIB5xx Demo Application

; TT = "LOCAL",- ;Translation Type
; NA = "510_403_1",- ;Name of application directory
; AS = "HOT",- ;Application state (COLD,WARM,HOT)
; PH = %l_Global_Paths,-
; SV = %SV,- ;System variable (RESERVED)
; CP = "SHARED",- ;Color Allocation Policy
; RC = VECTOR("FILE_FUNCTIONS_CREATE_DIRECTORIES"),- ;Revision
compatibility
; HP = "DATABASE",- ;History Logging Policy ("DATABASE", "EVENT_LOG",
"NONE")
; EE = 0,- ;System Events & Operating System Events (1=Enabled,
0=Disabled)
; MO = %MON_MAP,- ;Monitor mapping
; PR = (1,2,3)) ;Printer mapping
;#CREATE APL1:B = %APL
;----------------------------------------------------
;Station Types
#SET STY3:BCX = "ANSI X3-28"

#SET STY4:BCX = "SPIDER RTUs"
#SET STY5:BCX = "SINDAC (ADLP80 S)"
#SET STY6:BCX = "P214"
#SET STY7:BCX = "SINDAC (ADLP180)"
#SET STY8:BCX = "PAC-5"
#SET STY9:BCX = "SATTCON/COMLI"
#SET STY17:BCX = "LON"
#SET STY20:BCX = "LCU 500"
#SET STY21:BCX = "SPACOM"
#CREATE STY22:B = LIST(NA = "SPI", DB = "STA", CX = "S.P.I.D.E.R/RP570")
#CREATE STY23:B = LIST(NA = "LMK", DB = "REX", CX = "LonMark")
#CREATE STY24:B = LIST(NA = "ADE", DB = "STA", CX = "Ademco")
25
#CREATE STY25:B = LIST(NA = "PCO", DB = "STA", CX = "Procontic / RCOM")

#CREATE STY26:B = LIST(NA = "WES", DB = "STA", CX = "Westinghouse")
#CREATE STY27:B = LIST(NA = "ATR", DB = "STA", CX = "Alpha Meter")
#CREATE STY28:B = LIST(NA = "PLC", DB = "RTU", CX = "PLC")
#SET STY29:BCX = "IEC"
#SET STY30:BCX = "DNP"
;----------------------------------------------------
;Node, Link for PC-NET & Stations
@i_Status = do (read_text("Sys_Tool/Create_C.scl"), "BASE_SYSTEM")
;----------------------------------------------------
;LAN node name of the computer
@t_lan_node_name = "Basesystem1"
@i_system_node = SYS:BND
#set nod’i_system_node’:bnn = %t_lan_node_name
;----------------------------------------------------
;Other Stations
;NOTE! Use the system configuration tool to create stations for the PC-NET!
;NET 1 (DCP-NET) stations

;#CREATE STA:V = LIST(-
; TT = "EXTERNAL",-
; ST = "RTU",-
; ND = 1,-
; TN = 1)
;#CREATE STA1:B = %STA
If the MicroSCADA base system revision 8.4.2 or later is used

together with applications that were created with earlier revisions of
the base system, for example by using LIB 4.0.1, the revision
compatibility switch NO_ALIAS_CHECKING should be turned on.
This is done by adding "NO_ALIAS_CHECKING" to the RC
attribute of the application in SYS_BASCON.COM.
SYS_BASCON.COM:

...
RC =
VECTOR("FILE_FUNCTIONS_CREATE_DIRECTORIES" ,"NO_ALIAS_CHECKING") ,-
...
SYS_NETCON.COM
The default SYS_NETCON.COM file has the following contents:
;#PAUSE 10
;@A=LOAD_DCP("SYS_NET.1MB",1,1);LOAD NET1 ON LINK 1
;@A=LOAD_DCP("My_NET_FILE",2,1);LOAD NET2 ON LINK 2
By removing the semicolons from the file, you can make it load and start the internal
communication units next time it is executed.
26
4. Communication system object definitions

This chapter describes the definition of the communication system objects. It
contains the following three sections:
4.1 An overview of the communication system objects and the alternatives
for defining communication system objects.
4.2 Configuring NETs off-line: the preconfiguration of the DCP-NETs and
the initialization file of the PC-NETs.
4.3 Configuring NETs on-line: the principles for defining and modifying
communication system objects with SCIL, defining communication
system objects in the SYS_NETCON.COM configuration file and
configuring NET start-up.
The communication system objects and their attributes are detailed in the System
Objects manual.
4.1. Overview
Communication system objects

Each communication unit contains a set of system objects which specify the unit
itself, the line properties and connected devices etc. A NET unit is completely
configured by the following system objects:
• A NET object for the definition of the NET unit itself
• A NET object for each directly or indirectly connected base system and NET unit
• NET line definitions such as line protocol, data transmission rates, etc
• An APL object for each application in the connected base systems
• A PRI object for each directly connected printer
• A STA object for each directly and indirectly connected station
Defining communication system objects

The communication system objects can be defined both off-line (the NET is out of
operation) and on-line (NET in operation).
The off-line configuration comprises:
• The DCP-NET’s preconfiguration written off-line by a configuration tool, see
Section 4.2.
• The PC-NET configuration with the System Configuration Tool and automatic
updating of the initialization file.
• When started, the PC-NETs read an initialization file which contain the most
fundamental definitions.
The on-line configuration can be done with SCIL or tool pictures as follows:
• The SYS_NETCON.COM executed at each base system start-up may contain
SCIL statements for defining communication system objects.
• The communication system objects can be changed with SCIL programs started
automatically or manually.
• The objects can also be changed with tool pictures.
27
The on-line configuration can be read into the System Configuration Tool by
selecting Configuration - Open On-line. Reading the on-line configuration sets the
tool into On-line mode.
4.2. Defining communication system objects off-line
Preconfiguration with the system configuration tool

The System Configuration Tool configures the LIN and NOD base system objects
needed for the PC-NET. All configurable attributes of the LIN:B object and NOD:B
object can be changed from the tool. The initialization file pc_net.cf1 is updated
automatically.
Preconfiguration in DCP-NETs
The DCP-NET communication program which runs in the board based
communication units contains what is called a "preconfiguration". The
preconfiguration is a set-up of system objects and attributes which functions as a
default configuration. Each time the NET unit is loaded and started the
preconfiguration becomes valid.
The preconfiguration can be viewed, edited and documented off-line with a program
called NETCONF which runs in the DOS environment or during operation from the
base system by means of a preconfiguration tool picture.
Changes made in the preconfiguration come into force, when the communication
program is loaded into the communication unit the next time.
The preconfiguration has the following limitations:
• A maximum of 20 stations per unit can be preconfigured
• Some attributes cannot be preconfigured
The required configuration blocks are described in this manual and the attributes are
found in the System Objects manual.
PC-NET configuration with the System Configuration Tool

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 pc_net.cf1 file 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 automatically created by the System Configuration Tool.
Initialization file of the PC-NET

When the PC-NET program is started, it reads the initial configuration file
PC_NET.CF1, which is a text file located in the SYS_ directory. It defines the basic
communication nodes and addresses to enable the communication to an application
28
that will download the total configuration. The initial configuration file is
composed of a number of lines, each of which specify an attribute (see below). The
attributes are referred to with the notation:
object.attribute
The possible objects are:
local_node The PC-NET itself
ext_node An external node (the base system where the NET
is situated)
ext_apl An application in the base system where the NET is
situated
In case the PC_NET.CF1 file is missing when the PC-NET is started, a default
configuration becomes valid.
The following PC_NET.CF1 file is included in the MicroSCADA delivery:
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
All line and station configuration of the PC NET, as well as the definition of other
nodes and applications can be done with the System Configuration Tool (with User-
Defined Programs, if not supported by the tool yet). The usage of the tool is
described in the Connecting LONWORKS Devices to MicroSCADA manual.
4.3. Defining communication system objects on-line

The on-line changes take effect immediately. However, if the NET unit is stopped
and restarted, the on-line changes will be lost and the preconfiguration will be
restored. On-line 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 NET unit has been restarted.
Principles
The procedure for creating communication system objects is as follows:
• Define the NET line to be used by assigning it the desired protocol (the PO
attribute, see Chapter 12).
• Give the line its communication properties by means of the line attributes
(Chapter 12).
• Create the object by giving it an object number and assigning it the line number.
• Set the attributes of the created object.
• Take the line and the device into use.
29
In SCIL, communication system objects are created and deleted using NET
attributes, see the System Objects manual, Sections 12.3.1 - 12.3.5. When adding a
device, the NET line must first be defined. NET lines are defined by the NET line
attribute PO. See examples 4 and 5 in Section “Modifying communication system
objects with SCIL” on page 30.
Most attributes can be both read and written on-line with SCIL commands. The
attributes are accessed with the object notation according to the format:
OBJnn:Sati
'nn' Object number (device number)
'at' Attribute name
'i' The possible index
The object notation is detailed in the System Objects manual.
The attributes are written with the #SET command according to the format:
#SET OBJnn:SATi = value
See Example 1 in Section “Modifying communication system objects with SCIL”
on page 30.
The line attributes can be changed with the SCIL command #SET:
#SET NETnn:Sati = value
'i' Line number
When a new line or device is created on-line, its attributes get the default values
given in the System Objects manual.
Modifying communication system objects with SCIL

By changing attributes, it is possible to define new devices (create new system
objects), switch over a device from one line to another, and even redefine a line for
another protocol.
Changing the line protocol on-line requires that the line is first removed and then
added again with the new protocol. First the line must be taken out of use as
described below. In addition, all devices on the concerned line must be removed by
setting the attributes which create them to "D". A line is removed from the
configuration by setting its PO attribute to 0. A new line is created by setting the PO
attribute of the line to the line protocol value (System objects, Section 13.2.). See
examples 3 and 4 below.
Changing the line attributes on-line generally requires that the actual line is taken
out of use, i.e. setting IU = 0, while the change is performed. After the modification,
the line is restarted by setting the IU attribute to 1. See Example 2 below.
Example 1
Changing the printer type of PRI2:
#SET PRI2:SIU = 0 ;The printer is taken out of use.
#SET PRI2:SPT = 7 ;The printer is changed to a pixel-based colorprinter.
#SET PRI2:SIU = 1 ;The printer is taken into use.
30
Example 2
Changing the transmission rate on line 1 of NET1:
#SET NET:SIU1 = 0 ;The line is taken out of use.
#SET NET:SBR1 = 1200 ;The baud rate is changed.
#SET NET:SIU1 = 1 ;The line is taken into use.
Example 3
Removing line 2 of NET1, when two stations (STA1 and STA2) are connected to
the line:
#SET STA1:SIU = 0
#SET SAT2:SIU = 0 ;The station is taken out of use.
#SET NET1:SIU2 = 0 ;The line is taken out of use.
#SET NET1:SST1 = “D”
#SET NET1:SST2 = “D” ;The stations are deleted.
#SET NET1:SPO2 = 0 ;The lines are deleted.
Example 4
Adding a printer on line 2 of NET1:
#SET NET1:SPO2 = 4 ;Line number 2 is created as a printer line.
#SET NET1:SIU2 = 1 ;The line is taken into use.
#SET NET1:SPR4 = 2 ;Printer number 4 is connected to line 2.
Example 5
Adding three stations of type S.P.I.D.E.R. (STA1, STA2 and STA3) on line 4 of
NET1:
#LOOP WITH NR = 1 .. 3
#SET NET1:SRT’NR’ = 4 ;Station number ‘NR’ is connected to line 4.
#SET STA’NR’:SSA = %NR ;The station address of the station.
#SET STA’NR’:SAL = 1
#SET STA’NR’:SIU = 1
#LOOP_END
SYS_NETCON.COM
The base system recognises and executes a file called SYS_NETCON.COM which
is a text file containing SCIL commands. The file is executed each time the base
system is started. Normally, the file contains only commands for starting possible
internal frontends by means of the SCIL function LOAD_DCP (see the
Programming Language SCIL manual, Section 8.10.). However, it can also contain
statements for reconfiguration of NET objects provided that there is a time delay of
at least 5 seconds (achieved with the #PAUSE command) between the start-up of an
internal frontend and the subsequent configuration statements.
Only NET objects can be configured in SYS_NETCON.COM.

Configuring STA and PRI system objects is not possible.
The SYS_NETCON.COM file can be edited with a text editor in Windows

environment, e.g. Notepad, or with the MicroSCADA SCIL Program Editor (see
Programming Language SCIL, Chapter 12). The SYS_NETCON.COM file must be
stored in ASCII format.
31
NET start-up configuration with SCIL

A command procedure for on-line reconfiguration of NET could be started as
follows:
• When a 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 may be used for
updating a process object which activates an event channel, which in turn starts a
command procedure with reconfiguration commands. See “System message
handling” on page 161.
• When the connection between NET and an application recovers after a break,
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, i.e., reconfiguration takes place if NET has been
restarted, not if the application has been out of use. This can be checked, e.g. by
reading a system object attribute configured on-line. If on-line configuration
changes are valid, NET has not been out of operation.
Reconfiguration commands could also, for example, be included in the command
procedures started by the event channels APL_INIT_1 and APL_INIT_2,
(APL_INIT_H in Hot Stand-by systems, see the Application Objects manual,
Section 8.3.). However, a NET unit can be restarted even though the application is
not.
NET start-up configuration with the System Configuration Tool

The System Configuration Tool creates procedures for automatic start-up and
configuration 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 the on-line 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 will be removed and a warning will be generated (notify
window, log file).
• The command procedure SYS_INIT_1:C calls a text file (StartPCNET.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:
local_node.sa Taken from the stored configuration
local_node.nn Taken from the stored configuration
ext_node(1).sa Own base system station address (SYS:BSA)
ext_node(1).nn Own base system node number (SYS:BND)
ext_apl(1).nn Own base system node number (SYS:BND)
ext_apl(1).an Own application number (APL:BAN)
• 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
32
procedure SYS_NET'net_number'D:C. If the process object exists (e.g. created

by LIB5xx) and has an event channel connected to it, all the objects connected to
that event channel will be moved to the SYS_NET'net_number'D:A event
channel as secondary objects. In other cases, the tool automatically creates a
process object SYS_NETD:P('net_number'), to which the event channel
SYS_NET'net_number'D:A is connected.
• 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 will be
configured according to the information entered in the tool.
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 in the
tool.
33
5. Configuration data files

This chapter describes:
5.1 The general rules for the configuration data files of the communication
frontends. The data files are illustrated by an example.
5.2 The configuration parameters of the communication frontend.
5.1. General rules
Contained parameters
As mentioned above, the configuration parameters of the workstations are listed and
described in the workstation manuals. The parameters of the communication
frontend are described in Section 5.2. All the listed parameters need not to be
included in the configuration data files. Some parameters are mandatory only for
certain configurations and some represent optional features. Many configuration
parameters have default values (see the parameter lists), which are valid if no other
values are given for the parameters in the configuration data file. If the default values
are correct, the parameters need not to be included in the data files. The values given
in the data files replace the default values.
File format
The parameter definition lines of the data files can be arranged in any order. Each
line in the files has the following structure, see Figure 5.1.-1:
• The first six character positions of a line are reserved for the parameter name.
• The seventh position contains a blank space.
• The parameter value is written starting from position 8.
• After the parameter a comment may follow, indicated with a starting semicolon
(;).
Fig. 5.1.-1 The format of a line in the data files MFLCONF.DAT and
MWCONF.DAT
Editing the data files

The data files can be changed with a text editor (DOS format). They cannot be
changed while the workstation or frontend is in operation, because a modification
requires that the actual workstation or frontend (including the communication units)
is restarted.
35
5.2. Frontend configuration parameters
Frontend parameters
SRC Station Address of Frontend

The station address of the communication frontend must be unique among all nodes
(base systems, communication units and front-ends) in the entire MicroSCADA
network.
SRCNOD Node number of Frontend

Value: 1 ... 32
Default value: Station address - 200
Base system parameters

The communication frontends can be connected to up to four base systems, each of
which is identified by a sequence number 1 ... 4. The sequence number is related to
a certain base system by the DST parameter, see below. The base system
communication parameters must always be included in the frontend configuration
data file MFLCONF.DAT, unless the given default values are accepted.
DI Diagnostic Command Interval

MFL sends cyclically diagnostic commands to the base systems when there is no
other communication. This parameter specifies the time interval between the
commands.
Type: Integer
Value: 0 ... 65535
The time interval in seconds
0 = no diagnostics
Default value: 15
Indexing: Base system sequence number, 1 ... 4
If index is omitted, the value is valid for all the base systems
DST Station Addresses of Connected Base Systems

The station addresses of the base systems to which the frontend is connected. This
parameter is the value of SYS:BSA in the connected base system, see the System
Objects manual, Chapter 4.
If omitted, index = 1
36
NOD Node number of base system

Value: 1 ... 32
PROT Protocol
The link layer protocol used in the communication with the base system.
0= ANSI X3.28 (using a COM port)
2= TCP/IP (possible if the base system computer is PC /Windows)
Default value: 0
NET Parameters
Each communication frontend can contain up to four communication units (NETs)
connected to the RAM interface. In the MFLCONF.DAT file the individual units
are identified by a board index (interface number), 1 ... 4. The indexes are related to
the I/O base addresses, IRQ levels and RAM window locations of the DCP/MUXi
boards as follows:
Index I/O address IRQ RAM address
1 33CH 5 D0000H ... D3FFFH

2 2BCH 12 D4000H ... D7FFFH
3 23CH 15 D8000H ... DBFFFH
4 1FCH 3 DC000H ... DFFFFH
CMOD Initial mode of NET

0= single mode of NET
1= redundant hot
2= redundant stand-by
Default value: 0
Indexing: Board index
0 = single (no redundancy) see above
If omitted, index 1
CSRC NET Station addresses

The station address, the AS attribute, of the NET (see System Objects, Chapter 12).
This parameter is only needed when a NET unit or base system is connected to a
serial line of the NET unit in question (specified by the index). The parameter name
may occur several times in the configuration file, with different values, if several
base systems or communication units are connected to the same unit.
Indexing: Board index, see above
If omitted, index 1
37
CPNOD Peer node number of NET

The node number of the partner NET in a redundant relationship. The parameter has
no meaning, if there is no redundancy.
Indexing: Board index, see above
If omitted, index 1
TCP/IP interface parameter

The following parameter is mandatory, if TCP/IP communication is used:
HOST TCP/IP Host Name

The internet address or host name of the base system computer given either as host
name/alias name or with dot notations. The parameter is valid only for TCP/IP
communication, i.e. PROT = 2.
Indexing: Base system sequence number, 1 ... 4 (see the Base system
Communication Parameters above)
No index = index 1
Examples:
HOST SPIDER
HOST 130.0.9.130
Comments are not allowed on this parameter line.
Serial communication parameters

The following parameters are meaningful only when the frontend is connected to a
base system through serial lines and a COM port. If a base system is connected on a
COM port, an external clock cannot be connected, see below. Likewise, if an
external clock is connected to a COM port, it is not possible to connect a base system
this way.
BR Baud Rate
The transmission rate used on the line.
Recomm.: BR = 9600
COM Communication Port

The communication port used for serial communication with the base system.
Value: 1 = COM1
2 = COM2
Default value: 1
38
EN ENQ Limit
See the EN attribute in the System Objects manual, Chapter 13.
Type: Integer
Value: 1 ... 255
ER Embedded Response
For more information, refer to the System Objects manual, Chapter 13.
Value: 0 = No
1 = Yes
NA NAK Limit (1 ... 255)

See the NA attribute in the System Objects manual, Chapter 13.
PY Parity
See the System Objects manual, Chapter 13.
Value: 0 = no parity
1 = odd parity
2 = even parity
Recomm.: Even parity (PY=2)
RE Redundancy
See the System Objects manual, Chapter 13.
Value: 0 = No redundancy
(1 = CRC, not supported)
2 = BCC
Recomm.: RE = 2
TI Timeout Length
See the TI attribute in the System Objects manual, Chapter 13.
Type: Integer
Value: 1 ... 255
External clock parameters

The following parameters apply, when an external clock is connected to a COM
port of the PC:
COMAG COM Port for ASCII General

The number of the COM port (1 or 2) reserved for time synchronization using the
General ASCII protocol. Only one COM port at a time is available for serial
communication (software limitation). Hence, if a COM port is used for time
39
synchronization, no base system can be connected through a serial line, or, if a base
system is connected via a COM port, time synchronization of the frontend is not
possible.
Values: 0 = no external clock (default)
1 = COM1
2 = COM2
CLOCK Clock Type

The type of clock used on the COM port specified by the COMAG parameter.
Values: 1 = COMPUTIME
2 = RCC8000
5 = GPS166
6 = TRIMBLE
MODE Synchronization Mode

Currently needed only if CLOCK = 6. In that case MODE should be given value 6.
Internal clock parameters

The following parameters are required, when the Meinberg radio clock boards
PC31 and PC32 are used for clock synchronization:
TZ_MIN Time zone (minutes)

Time zone dependent correction added to the time received from the radio clock.
Value: -720 … 720
CF Clock read frequency

Clock read frequency (cycle) in seconds. The parameter determines how often the
time will be read from the PC31/PC32 clock and written to the NET boards. The
value should be an adjusting between the demands for accuracy and the increased
load caused by the readings.
Default value: 0 = no reading
CA Clock address
The I/O address of the radio clock.
Default value: 768 ( = 300H)
40
6. Base systems
6.1 The fundamental configuration of a base system and its applications.
6.2 How to configure intercommunication between two applications in the
same base system or in separate ones. The base system configuration
additions and modifications required by various installations are
described in detail in Chapters 7 ... 14. Chapter 3 describes the structure
of the SCIL program blocks for base system object definition.
6.1. Configuring a base system
Fundamental definition (SYS)

Create a SYS:B object with at least the following attributes (see the example in
Figure 6.1.-1):
ND The node number of the base system. The node number must be
unique within the entire MicroSCADA network, see Chapter 7.
SA The MicroPROTOCOL station address of the base system. Like
the node number, the station address must be unique within the
network, see Chapter 7.
The following attributes are optional:
ER The use of the base system as a routing node. It means that if
routing is enabled in a specific base system, it can route
messages addressed to other nodes. See Section 4.2.4. in System
Objects.
DN, DS The default node number and default station type. These
attributes should not be used!
SH Shadowing attribute. This attribute is used for the configuration
of hot stand-by, see Chapter 14.
TI Timeout length for node communication. The attribute can be
locally and temporarily sidestepped by a SCIL function
(TIMEOUT).
PC, RC Memory cache space attributes, see ‘Tuning memory
parameters’ in this section.
FS File Sync. The flushing of buffered data onto disk.
DE Allowing applications in the base system to be accessed by other
software using DDE.
AA The use of standard audio-visual alarm unit.
CA, CF, CL, TZ Attributes related to an external clock, see Chapter 10 or Section
4.3.2. in System Objects.
SD, SP SPACOM devices connected directly to the base system.
DM, TF Debug mode and time format.
41
The following attribute is read-only and is therefore not set:

DU The attribute states whether the DDE server is usable or not. Its
value is 0, if the DDE server has not been started. If the DDE
server has been started, its value is 1 if a user has logged on to
the base system computer, otherwise 0.
The SYS:B object definition must come first in the base system
configuration file SYS_BASCON.COM, otherwise the system will
not start.
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:
• One link for the LAN. The definition of LAN links is described in Chapter 8.
• Two RAM links for internal DCP NETs. The RAM links are described in Section
9.2.
• One Integrated link for a PC NET. (Created by the System Configuration Tool.)
Nodes (NOD)
Nodes are directly or indirectly connected base systems, communication units, and
communication frontends. The nodes are defined by NODn:B objects
(n = 1 ... 250). A node definition is needed for:
• Communication with another base system. This is described in Section 6.2.
• Communication through the communication units. Each NET unit - DCP NETs
as well as PC-NETs - which will be recognized by the base system must be
defined as a node. These node definitions are described in Chapter 9.
• Reading and writing the attributes of communication frontends. 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.
Devices (MON, PRI, STA)

The monitors, printers and stations are defined as MONn:B (n = 1 ... 100), PRIn:B
(n = 1 ... 20) and STAn:B (n = 1 ... 5000) objects respectively.
The required MON definitions are described in Chapter 10, PRI objects in Chapter
11 and STA objects in Chapter 12.
42
Local applications (APL)

A local application is situated in the base system in question, which means that all
the application software is stored in the 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.
The application directory branch with its subdirectories must exist

before a local application can be defined in the base system
configuration (see the Installation manual).
Base system 1
Node Number: 9
Station Address: 209
APL1 APL2
Base System Configuration Application 1:

Base system NA = SAMPLE , -
#CREATE SYS:B = LIST(- AS = HOT , -
ND = 9, - MO = (-1, -1, -1, -1, -1)-
SA = 209, - TT = LOCAL )
PC = 1000,- #CREATE APL1:V = %APL
RC = 500 )
Application 2:
Concerning the definition of links, #CREATE APL:V = LIST (-
nodes, monitors, printers and NA = TUTOR ,-
stations, see the examples in AS = HOT ,-
the subsequent chapters. MO2 = 2, -
TT = LOCAL )
#CREATE APL2:V = %APL
Example_defin.eps
Fig. 6.1.-1 An example of the fundamental definition of a base system and the
definition of two local applications.
To configure a local application in the base system:
Create an APLn:B object ('n' = 1 ... 250) and assign it the following attributes (see
the System Objects manual, Chapter 5):
NA Application Name. The application name is the name of the
application directory branch containing the application software
(e.g. "SAMPLE" according to the example above).
MO Monitor mapping, see the headline "Device Mapping" below.
AS "HOT" if the application will be running.
AP Application mapping if the application will communicate with
other applications within the same or in different base systems
(see Section 7.2).
ST, PR Printer and station mapping. These attributes are generally not
needed, see the headline "Device Mapping" below.
43
TT "LOCAL"
EM, HB, PM History buffer and queue lengths, see the headline "Tuning
Memory Parameters”.
PQ Number of parallel queues.
QL Maximum length of process queries.
See the examples in Figure 6.1.-1.
At least one local application must 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).
The application that is created first in SYS_BASCON.COM will be the default
application. If no application number is given when opening a MicroSCADA
monitor, the default application is chosen. Likewise, if no application number given
when using the program interface, the default application is addressed.
Device mapping
Monitors, printers and stations can be mapped for an application, which means that
the application recognises the devices under logical numbers.
The station mapping, for instance, specifies the station numbers under which the
application will know the stations. The station mapping has the following format:
APLn:BSTi = j
‘i’ The logical station numbers as known to the application and the
values
‘j’ The STA object numbers of the stations
The printer mapping works in a similar way and also the mapping of semi-graphic
workstations. Printers and stations can be mapped for several applications
simultaneously, while the semi-graphic workstations are reserved for the application
when mapped.
The printers and stations have a default mapping, which means that each logical
application recognises 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 (i.e. i = j), i.e. do not change the default values of
printer and station mapping.
The monitor mapping is described in Chapter 10.
Tuning memory parameters

The allocation and use of the available RAM memory is affected by the following
base system attributes:
• The SYS:B attributes PC (= Picture Cache Size) and RC (= Report Cache Size),
see the System Objects manual, Chapter 4.
• The APLn:B attribute HB (= History Buffer), see the System Objects manual,
Chapter 5.
44
• The picture cache and report cache memory space is common to all the
applications in the base system. The cache memories contain only objects and
pictures that have been in use, but are not currently running. The maximum cache
space is specified by the PC and RC attributes. When these limits are reached, the
least used objects are removed.
During operation, there should be at least 500 kB free memory. The MF, MS and
MU attributes can be used for reading the occupied and the free memory space (see
the System Objects manual, Section 4.2.5). If there is not enough free memory,
memory is taken from the picture and report caches.
6.2. Communicating applications

Communication between applications means that the object data in one application
can be read and written from another one by means of the object notations.
Communication between applications in the same base system, i.e. 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 direct serial lines,
through LAN or through frontends, see Figure 6.2.-1. 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 need not to be defined. It is recommended not to have more than three
communication units between two communicating base systems.
45
Base system 1
Node Number: 9
APL1 APL2
Base System Configuration Application 1:

Base system NA = SAMPLE , -
#CREATE SYS:B = LIST(- AS = HOT , -
ND = 9, - MO = (-1, -1, -1, -1, -1)-
SA = 209, - TT = LOCAL )
PC = 1000,- #CREATE APL1:V = %APL
RC = 500 )
Application 2:
Concerning the definition of links, #CREATE APL:V = LIST (-
nodes, monitors, printers and NA = TUTOR ,-
stations, see the examples in AS = HOT ,-
the subsequent chapters. MO2 = 2, -
TT = LOCAL )
#CREATE APL2:V = %APL
Example_defin.eps
Fig. 6.2.-1 Base system 1 can be configured to access the database of the
applications in base systems 2 and 3 as described in Section 6.2.
Communication between base system 2 and base system 3 requires
that there is an external application in base system 1, which forwards
the data between the two base system.
Local applications
Suppose that application 'a' needs to read and write data in application 'b' in the
same base system (see Figure 7.1.-1). Application 'b' must then be "introduced to"
application 'a' by means of application mapping (see the System Objects manual,
Section 5.3.):
#SET APLa:BAPi = b
where
'i' The logical application number under which application 'a'
recognises application 'b'
If there are no obstacles, let the logical number be the same as the object number of
the application, i.e. '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, e.g. with the notation: OBJ:2POV1.
46
Fig. 6.2.-2 An illustration of the data communication between applications in the

same base system
Base system configuration:

(See Figure 6.2.-1.)
Application 1:
...
#SET APL:VAP2=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, see Chapter 8 and Chapter 9). If base system 2 is connected via several
communication units, the link to the nearest unit will be used.
2. Create a NODn:B object representing base system 2, where 'n' is the node
number of base system 2. The NODn:B object must 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
47
In addition, if LAN is used:

NN LAN node name of base system 2 (see “LAN nodes” on
page 55).
In some special cases, a routing node must be defined, see the RN attribute in the
System Objects manual, Section 8.2. This applies the communication between a
base system connected to a communication frontend via LAN or COM port, and a
base system connected to a NET unit in the frontend. If no routing node is defined,
the communication must be initiated from the latter base system, e.g. by means of
an object notation.
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), i.e. 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’ will recognize application ‘b’. If there are
no obstacles, let the logical number be the same as the object number of the
application (i.e. 'i' = 'b').
Fig. 6.2.-3 An illustration of the configuration and data communication between two applications situated in
separate base systems
48
LAN link configuration

(See Figure 6.2.-3.)
;LAN link:
#CREATE LIN1:B=LIST(-
LT="LAN",-
TR="TCP/IP")
;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)
49
7. MicroSCADA networks
7.1 The global definitions in a MicroSCADA network: the node numbers,
and the ACP (MicroPROTOCOL) station addresses.
7.2 The object numbering which is unique within a certain base system or
communication unit.
7.1. Global definitions

The MicroSCADA configuration software contains some global definitions which
must correspond in all configuration modules throughout the entire MicroSCADA
distributed network. These are the node numbers and the ACP station addresses, see
Figure 7.1.-1. ACP is the MicroSCADA internal protocol previously called
MicroPROTOCOL.
The node numbers and station addresses can be changed any time. However, if the
network is extensive, a change of node number or station address may require
reconfiguration in several modules. It is therefore recommended to assign the node
numbers, and the station addresses to fixed values which are regarded as non-
editable data.
In a Local Area Network (LAN), the connected computers - base system,
workstations and frontend computers have a LAN node address which is not to be
confused with the MicroSCADA node numbers. Likewise, if LONWORKS network is
used for process communication, the LONWORKS devices are defined by node
numbers. These have nothing to do with the MicroSCADA nodes.
Nodes
In the MicroSCADA network, the base systems and communication units (NETs)
are regarded as nodes. Each of them are given a node number which must be unique
throughout the entire MicroSCADA network. Likewise, the communication
frontends are nodes with unique numbers.
The node numbers can take integer values from 1 to 32 (limited by the NET
program). However, for compatibility reasons, it is not recommended to give the
NET nodes numbers above 19. A suitable convention could be to assign the NET
units sequential node numbers from 1 and upwards, and the base systems, likewise,
sequential node numbers starting from a number which is large enough. For
instance, if the NET nodes are less than 8, the base system node numbering could
start from 9.
In the base systems, the communicating nodes are defined by NODn:B objects,
where 'n' is the node number. In the communication units, the nodes are defined by
NETn:S objects, where 'n' is node number.
51
Fig. 7.1.-1 The global definitions and the object numbers of a typical MicroSCADA network. The figure also
includes the base system specific link numbers and the NET unit line numbers
Station addresses
Each base system and NET unit has an ACP station address, which must be unique
within the network of intercommunicating devices.
52
Devices which never communicate and which are not recognized by the same NET
unit or base system may have the same station address.
The station addresses can take integer values from 1 to 254. A widely used
convention when assigning station addresses is as follows:
Base systems: 200 + node number
Communication units: 200 + node number
7.2. Object numbering

Each MicroSCADA monitor, printer, station and application that is included in the
network has an object number. The object numbers of monitors, devices, printers,
stations and applications are unique within the base system that uses them. The
printers, stations and applications are also given object numbers, which are unique
within the NET unit that they are directly connected to.
Though the object numbers need not to be globally unique, the configuration work
is simplified by keeping them unique as long as possible. This means that a certain
device is assigned the same object number in all base systems and communication
units, see Figure 7.1.-1. In principle, the object numbers can be changed any time.
However, it is generally not recommended to change the numbers in a working
system.
Each connection line has a number which is unique for the base system or NET unit
in question. The numbers of the NET unit lines are identical with the physical
numbers of the lines. In a base system, the links to other base systems,
communication units and workstations are numbered 1 ... 20. Figure 7.1.-1 includes
the NET unit line numbers and the base system link numbers.
Monitors (MON)
The monitors are symbolized with the object name MON. The MON objects can
take numbers in the range 1 ... 100.
Each monitor that the operator starts to view and supervise a MicroSCADA
application is regarded as a MicroSCADA monitor. A MicroSCADA monitor can
contain several monitors for supervising one or more applications. All monitors that
are available for the base system must be defined as MON objects.
Printers (PRI)
The printers are notated by PRI object names. The PRI objects can take numbers 1
... 20 in the base systems and 1 ... 8 in NET.
Stations (STA)
The stations are notated by the object names STA. They can take numbers 1 ... 2000
in the base systems and 1 ... 255 per station type in the communication units (limited
by the RAM size in NET).
Applications (APL)
The applications are notated by the object names APL. Each base system can contain
up to 250 applications, while each NET unit can recognise up to 32.
53
8. Local area networks (LANs)

This chapter describes how to configure MicroSCADA for LAN communication.
The chapter does not describe the LAN product specific configuration. For more
information about this, refer to the LAN product manuals.
Base system configuration

In order to connect a base system to a LAN:
Create a LINn:B object with the following attributes (see the System Objects
manual, Chapter 7):
LT = "LAN"
TR = "TCP/IP"
All workstations, base systems and frontends can utilise the same LIN object, i.e.
only one LIN object definition is required. No LIN object is required for the LAN,
if the base system uses LAN only for communication with workstations running X
software.
Frontends
In each communication frontend the LAN communication is established with the
following definitions in the configuration data files:
1. Set the parameter PROT = the LAN protocol used, i.e. TCP/IP.
2. Set the HOST parameter to the LAN node number of the connected base
system.
The parameters can be indexed by a base system number for communication with
several base systems, see the parameter descriptions in Section 5.2.
LAN nodes
In the LAN network, each connected base system, workstation and frontend has a
LAN node name or number (see your LAN product manual). The LAN node names
are used in the MicroSCADA configuration to achieve communication between
base systems (see Section 6.2.), between base systems and workstations, as well as
between base systems and frontends.
The LAN node names are assigned during the installation of the LAN network.
55
Base System with Internal NET

Base System 3
Node Number: 11
Station Address: 211 Apl5
RAM Interface - link 1
Communication Unit 3
Node Number: 3
12345678
Serial lines (COM port)
Basys_Internal_NET.eps
Base System Configuration

;LAN link:
;
#CREATE LIN1:B=LIST(-
LT=”LAN”,-
TR=”TCP/IP”)
Front-end Configuration (in MFLCONF.DAT)

PROT1 2
HOST1 90.0.1.124
PROT2 2
HOST2 90.0.1.127
Fig. 8.-1 An example of a MicroSCADA configuration for a LAN
56
9. Process communication system

This chapter describes how to configure the process communication units (NETs)
and how to configure networks of interconnected NETs and base systems:
9.1 How to configure a NET unit (NET): the fundamental configuration of
DCP-NETs and PC-NETs, the configuration of applications known to
the unit and some general rules.
9.2 How to configure a base system and an internal DCP-NET.
9.3 How to configure a base system and a PC-NET.
9.4 How to configure a communication frontend connected to two base
systems via a LAN.
9.5 How to configure networks of connected NETs and base systems.
The configuration measures required for various device connections in NET
(stations and printers) are described in the Chapters 10-13.
9.1. Configuring a communication unit (NET)

Fundamental configurations, DCP-NETs
To make the communication unit work and communicate with the base system:
1. Define the communication unit itself in the preconfiguration as “This node”:
Device number = the node number of the unit (see Chapter 6)
RAM size = 1024 for DCP-286i and DCP-386i type boards, 512 for DCP/
MUXi type NET boards
SA = ACP station address of the unit (ACP is the MicroSCADA
internal protocol)
MS = Message application for the system message
SE = System message enabled
See the definition of "This node" in the examples of the figures in this chapter.
If the RAM size is wrong, the NET unit will not start.
2. Define line 13 (exists in the default configuration) for the common RAM
protocol.
3. Define external node for the base system.
LI = Line number of the base system; normally 13
SA = Station address of the base system
4. Define at least one application in the base system.
DN = Application number in the NET
TN = Application number in the base system
NN = Node number of the base system
57
Fundamental configuration, PC-NETs

The PC_NET.CF1 file is edited with the System Configuration Tool. The default
configuration includes the following definitions:
• The node number (local_node.nn) and station address (local_node.sa) of the
NET. Default: NET node number = 3, station address = 200 + NET node number.
• The node number (ext_node(1).nn) and station address (ext_node(1).sa) of the
base system where the NET will be running. Default: node number = 9, station
address = 209.
• The node number (ext_apl(1).nn) and application number (ext_apl(1).an) of the
application that the NET will initially communicate with (an application within
the same base system). Default: node number = 9, application number = 1.
Other basic NET definitions
The following definitions can be done in the preconfiguration (DCP-NETs) or with
SCIL. For PC-NETs, the definitions are made with the System Configuration Tool
(User-Defined Programs).
SX = The "destination address" defined in the ANSI stations
connected to the NET (has no importance if no ANSI station is
connected to the NET)
MS = System message application, see Section 15.1.
MI = System message identification; use as a process object address,
see Section 15.1.
SE = System message generation
0= off
1= on (recommended if not Hot Stand-by base systems)
2= start-up only (recommended in Hot Stand-by base
systems), see Section 15.1.
Lines (NET lines)
The definition of a line depends on the protocol to be used on the line, which in turn
depends on the device(s) connected to the line.
Each DCP-NET has 8 asynchronous serial lines numbered 1 ... 8. In addition, the
communication program recognises a line number 13 for common RAM interface.
This line is used for the communication between an internal NET unit and the base
system, between a NET unit in a communication frontend and a base system
connected to the frontend, as well as between the separate communication units in a
communication frontend.
The PC-NETs communicate through the serial ports (COM ports) of the host
computer and possible PCLTA cards (one or two) or the serial ports of a
“RocketPort”. The COM ports, if used, represent by default NET line numbers from
1 to 4: COM1 is line 1, COM2 is line 2, and so on. The NET line numbers of the
PCLTA card channels (up to two per board) can be freely chosen among the free
NET line numbers (1 ... 8 if no COM ports are used). A PC-NET communicates with
the base system (kernel) through line number 13 which is a software link (Integrated
link).
58
A NET unit line is basically defined by assigning it a protocol. This can be done in
the preconfiguration (DCP-NETs) or on-line with the PO attribute.
PC-NETs support the following protocols on the COM lines (lines 1 - 8): ACP, SPA,
LonTalk, RP 570 master and slave, RP 571 master, IEC 60870-5-101 master and
slave, IEC 60870-5-103 master and ALPHA. A COM port is taken into use by
assigning line 1 ... 8 one of these protocols. The output channels of the PCLTA cards
support only the LonTalk protocol.
The DCP board based NETs support all protocols supported by MicroSCADA,
except the LonTalk, ALPHA ME, IEC 101 and IEC 103 protocols.
The definition of lines is detailed in the contexts where various installations are
described.
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 definition
of the external nodes is described in Sections 9.2, 9.3, 9.4 and 9.5.
Applications (APL)
As a rule, all the applications in all base systems, which are directly or indirectly
connected to the communication unit, must 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. The default
applications of all the connected base systems (see Section 6.1.) should be defined
in the preconfiguration (DCP-NETs).
In order to define or redefine an application in a connected base system:
1. Define an “Application”, an APL object, in the preconfiguration or on-line by
means of the NETn:SSY attribute (see the System Objects manual, Chapter 14):
Device type = APL
Device number = Object number
Can be freely chosen within the NET unit (1 ... 32).
As far as possible, use the same application number
as in the base system. If message split is used
(see Section 11.2.), only the applications number 1
... 9 can be selected in the preconfiguration as
receiving applications.
Node number = The node number of the base system where the
application resides
Translated APL number = APL number in the base system
2. Assign it the following attributes for the communication supervision (System
Objects, Chapter 12):
SU = Application suspension time in seconds
SW = Application reply wait time in seconds
From SCIL, the SW and SU attributes are accessed as NETn:S attributes.
59
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 will be produced and the application
will be 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 S.P.I.D.E.R. RTUs connected to that application are not polled
until the communication with the application has been re-established.
Printers and stations (PRI and STA)
The configuration of the NET unit for connected printers and stations is described
in Chapter 11 (printers) and Chapter 12 (stations).
Memory allocations
The total RAM size of the DCP boards is 1024 kB (512 kB for DCP/MUXi). A part
of this memory space is reserved by the NET program itself, its fixed data areas and
stacks. The rest is allocated for external connections. The amount of free memory in
a unit may restrict the connection of devices to the unit. In order to learn the amount
of free memory space:
1. Start the NET unit for operation and read the existing amount of free memory
with the NETn:SFM attribute or by means of the configuration picture NET
SYSTEM CONFIGURATION, INTERNAL PARAMETERS.
The NET lines and the connected devices (system objects) allocate memory space
as follows:
Lines: About 1 kB per line + 0.33 kB per buffer
External nodes: About 2 kB/node
Stations: About 0.5 kB + memory areas (ANSI stations)
Printers: About 0.5 kB/printer
SPACOM: 1 kB per station + 50 byte/SPA point +
50 byte/event updated SPA point
STA memory areas: About 32 bytes per area
The memory allocation in NET is basically static in a run-time environment.
Memory is allocated and released only at configuration changes.
Buffer pool sizes
Each line has a buffer pool, the size of which is specified by the PS attribute (number
of buffers in the pool). One or a few buffers are reserved for message reception. The
rest of the buffer pool is divided between two priority levels.
The buffer pool sizes should be set according to the following principles:
• The pool size of a base system connection should be considerably larger than the
pool sizes of other lines. Recommended value: 50 ... 100.
• For other lines, the pool size should not be larger than necessary. Especially the
total pool size for all printer lines should be much less than the pool size for an
individual base system connection.
See also the recommendations in the System Objects manual, Chapter 13.
60
The general rule in NET is that one buffer is allocated for each message from a pool
of the destination line. For SCIL configuration commands, the buffer is reserved
from the base system line, since the command is handled within NET. For
communication commands, i.e., control commands, setpoint commands, printout
commands, etc., an additional buffer is reserved for the reply message. The buffers
are always returned to their home pools after use.
9.2. Internal NETs (DCP-NETs)

An internal NET is a DCP-NET placed within a base system computer and
connected to this base system through the common RAM interface. The NET unit
can be connected to other base systems and communication units through its serial
lines. A base system computer can house up to two internal NETs.
This section describes the configuration of a base system and an internal NET end.
The configuration is illustrated with an example in Fig. 9.2.-1.

In order to use an internal NET, configure the base system which will house the NET
as follows:
1. Create a LINn:B base system object for the RAM interface ('n' = 1 ... 20) and
assign it the following attributes (see the System Objects manual, Chapter 7:
LT = "RAM"
SD = Device name, "RM00" or "RM01" (see the Installation manual,
Chapter 5)
EN = Enquiry limit (rec.: 3)
NA = NAK limit (rec.: 3)
RE = Redundancy check: "NONE" or "BCC" (recommended)
TI = Time-out length in seconds (recomm. 1 ... 2 seconds)
The EN, NA, RE and TI attributes specify the communication properties and should
have the same values as the corresponding parameters in the communication unit,
see the line definition under the headline "Communication Unit Configuration"
below.
2. Create a NODn:B object for the communication unit, where 'n' is the node
number of the communication unit. Assign it the following NODn:B attributes
(see the System Objects manual, Chapter 8):
LI = Link number (= LINn:B object number)
SA = ACP station address of the communication unit
Concerning the node number and the station address of NET, see Chapter 6 and the
configuration of the NET unit below.
61
Base System with Internal NET

Base System 3
Node Number: 11
Apl5
RAM Interface - link 1
Node Number: 3
12345678
Serial lines (COM port)
Basys_Internal_NET.eps
Fig. 9.2.-1 An example of a configuration with a base system and an internal NET
The example includes only the definitions, which are of importance for this
particular configuration.
Base System:
ND = 11,-
SA = 211)
………………….
Link 1 (= RAM Interface):

#CREATE LN:V = LIST(-
LT = “RAM”,-
SD = “RM00”,-
RE = “BCC”,-
TI = 2,-
NA = 3,-
EN = 3)
#CREATE LIN1:B = %LIN
………………………
Node 3 (=Communication Unit 3):

#CREATE NOD:V = LIST(-
LI = 1,-
SA = 203)
#CREATE NOD3:B = %NOD
………………………
Application 5:
#CREATE APL:V
………………………;See fig. In Chapter 5
62
Communication unit configuration

Configure each internal DCP-NET unit as follows:
1. Perform the fundamental definition of the unit as described in Section 9.1.
2. Define line 13 with the RAM protocol (System Objects, Chapter 13):
PO = 3
MS = System message application, see Section 15.1
MI = System message object address, see Section 15.1
RE = 2 = BCC
TI = Time-out length in seconds, 1 ... 2 seconds
NA = NAK limit
EN = ENQ limit
PS = Buffer pool size, see Section 9.1
The RE, TI, NA and EN attributes should have the same values as the corresponding
LINn:B attributes in the base system configuration, see the LIN definition in "Base
system Configuration" above.
3. Define an "External node", a NET object, for the base system connected to line
13:
Device type = NOD
Device number = The node number of the base system
Line number (LI) = 13
Station address (SA) = Station address of the base system
4. Define an application, an APL object, for each application in the base system as
described in Section 9.1.
9.3. Configuring base systems with PC-NET

General
A PC-NET is a communication program which runs in the processor of the base
system computer. As communication lines it utilises the COM port of the PC or the
channels of the PCLTA card(s) or the ports of a “RocketPort”.
The configuration of a base system and a PC-NET is done with the System
Configuration Tool. The configuration is illustrated with an example in Fig. 9.2.-1.
The System Configuration tool includes the following main functions:
• Configuration of the base system and the PC-NET
• General mechanism for the base system configuration at system start-up
• General mechanisms for automatic starting and configuration of the PC-NET
• Online monitoring of the base system and the NET configuration
• Configuration of transceiver information and node and sub-net numbers of the
PCLTA card
• Debug support
63
For instructions on using the tool and more profound information, please refer to
Chapter 16 in this manual and the Connecting LONWORKS devices to MicroSCADA
manual.
The System Configuration tool can handle base system objects like links, nodes,
stations and station types. It can operate in the on-line or off-line mode, but a
combination is not supported. Operating in the off-line mode means that a
configuration can be built up without physical connections to the devices. If the tool
is switched to the on-line mode, the existing configuration will be read from the
current MicroSCADA base system. Stopping and starting the NET and the PCLTA
initialization can be done in the on-line mode only.
During the configuration work, the configuration data is read from permanent
configuration file using the off-line reading mechanism, or from the MicroSCADA
system (SYS 500 or COM 500) using the on-line reading mechanism. After the
reading mechanism, the current configuration is displayed inside the tool.
The System Configuration tool includes a function that checks the attribute limits.
In case of an invalid attribute value, it returns a string that requests the user to enter
a valid value. The tool also suggests default values for the attributes.
Base System with PC-NET

Base System 1
Node Number: 9
Apl1
Link1 = Integrated link
Link 13 = Integrated link

Node Number: 3
12345678
Serial lines (COM port) and LON lines
Basys_PCNET.eps
Fig. 9.3.-1 An example configuration of a base system with a PC-NET

PC-NET configuration
The tool configures the LIN and NOD base system objects needed for the PC-NET.
The PC-NET initialization file pc_net.cf1 is also updated automatically.
All the configurable attributes of the LIN:B object and the NOD:B object can be
changed from the Tool.
The tool creates procedures for automatic start-up and configuration 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 the on-line mode.
64
NET Nodes can contain user-defined SCIL programs. Each program receives its
environment as an input parameter, which in the NET Node level is the NET
Number.
9.4. Communication frontends

A communication frontend is a PC/DOS computer containing up to four
communication units. The communication units communicate directly with one to
four base systems. The units use the common RAM interface and the LAN, or the
serial port COM1 or COM2 for communication.
This section describes how to build a configuration composed of base systems and
a communication frontend. The described configuration is illustrated with an
example in Fig. 9.4.-1.

Configure each base system connected to a communication frontend via a LAN as
follows:
1. Create a LINn:B base system object for the LAN connection, see Chapter 8.
Only one LAN link per base system is needed, so if a LAN link already exists,
you need not to create any new LAN link.
2. Create a NODn:B base system object, where 'n' is the node number, for each of
the communication units in the LAN frontend. Assign it the following NODn:B
attributes:
LI = The link number of the LAN link (the LINn:B object number).
All units use the same link.
SA = ACP address. Each of the communication units must have a
unique station address, see Chapter 7.
Create a NOD object for the communication frontend, if its attributes should be
accessed from the base system, e.g. if the NETs in the frontend should be restarted
from the base system.
Configure each communication unit as follows:
1. Define the unit to itself as "This node" as described in Section 9.1.
2. Define line 13 with the RAM protocol:
PO = 3
MS = System message application, see Section 15.1.
MI = System message identification; use as a process object
address, see Section 15.1.
RE = 2 = BCC
TI = Time-out length in seconds
NA = NAK limit
EN = ENQ limit
PS = Buffer pool size, see Section 9.1.
65
3. Define an "External node", a NET object, connected to line 13 for each of the
connected base systems:
Device type = NOD
Device number = Node number of the base system
LI, Line Number = 13
SA = Station Address
4. Define an APL object for each application in the connected base systems as
described in Section 9.1.
Generally, there is no need for intercommunication between the two communication
units in the frontend and therefore they need not to know each others as nodes. This
is necessary only if any of the communication units is connected to one or more
other base systems through the serial lines of the units and these base systems
communicate via both the NETs. In these cases, configure the communication units
as follows:
5. Define each of the other communication units as an "External Node" (NET
object) situated on line 13:
Line = 13
Device type = NOD
Device number = Node number of the other communication unit
SA = Station address of the other communication unit
Frontend configuration file
The frontend itself is configured by the file MFLCONF.DAT which can be edited
with a text editor (see Section 5.2).
1. Check the following parameters for each of the base system connections and
edit if necessary:
SRC = The station address of the frontend
SRCNOD= The node number of the frontend
PROT = The LAN protocol used on the frontend - base
system communication: DECnet or TCP/IP
DST1 … 4= Station addresses of the base systems connected to
the frontend via LAN or the COM port
DI1 … DI4= Base system diagnostic interval
NOD1 … NOD4= Base system node numbers
If TCP/IP is used:
HOST1 ... HOST4= TCP/IP host names or internet addresses of the base systems
If a COM port is used:
COM= Serial communication port number, serial
communication attributes (BR, RE, PY, etc.)
CSRCn= Station address of the NET connected via DCP
NET card on a logical COM port
The index ´n´ in CSRCn depends on the IRQ of the
DCP-NET card in the frontend computer, see
Fig. 9.5.-1 and Section 5.2.
66
Example
Fig. 8.4.-1 shows a configuration where a frontend, COM 500 (base system 2) is
used by two base systems on LAN. The system configuration of base system 1,
COM 500 (base system 2) and base system 3 are listed below.
The example includes only definitions which are important for this particular
configuration.
Network of Base Systems and Frontends
Link 1
Base System 1 COM 500 (Base System 2)
Node Number: 9 Node Number: 6
Station Address: 206 Apl2
Communication Unit 1 Communication Unit 2
Apl1 Station Address: 201 Station Address: 202
Serial lines 12345678 12345678
Base System 3
Node Number: 11 Apl5
Node Number: 3
Serial lines 12345678
Basys_Nets_Frontends.eps
Fig. 9.4.-1 An example of a frontend used by two base systems
Configuration of Base System 1

Base System 1:
#CREATE SYS:V = LIST(-
ND = 9,-
SA = 209)
#CREATE SYS:B = %SYS
Link 1 (LAN link):
#CREATE LIN:V = LIST(-
LT = "LAN",-
TR = "TCPIP")
Node 1 (Communication Unit 1):

LI = 1,-
SA = 201)
LI = 1,-
SA = 202)
RN = 2,-
SA = 203)
Application 1:
#CREATE APL:V
...
67
Configuration of COM 500 (Base System 2)

COM 500 (Base System 2):
ND = 6,-
SA = 206)
Link 3 (Integrated link):
#CREATE LIN3:B = LIST(-
LT = "INTEGRATED",-
SC = "\sc\prog\pc_net\pc_nets.exe")
LI = 3,-
SA = 201)
LT = "INTEGRATED",-
SC = "\sc\prog\pc_net\pc_nets.exe \sc\sys\active\sys_\pc_net.cf2")
LI = 4,-
SA = 202)
Application 2:
#CREATE APL:V
...
Contents of pc_net.cf1 file for Communication Unit 1:

local_node.sa=201
local_node.nn=1
ext_node(1).sa=206
ext_node(1).nn=6
ext_apl(1).nn=6
ext_apl(1).an=2
local_node.sa=202
local_node.nn=2
ext_node(1).sa=206
ext_node(1).nn=6
ext_apl(1).nn=6
ext_apl(1).an=2
Configuration of Base System 3

Base System 3:
ND = 11,-
SA = 211)
68
LT = "INTEGRATED",-
SC = "\sc\prog\pc_net\pc_nets.exe")
LI = 3,-
SA = 203)
To access Communication Unit 2, the following definition is needed

RN = 3,-
SA = 202)
Application 5:
#CREATE APL:V
...

local_node.sa=203
local_node.nn=3
ext_node(1).sa=211
ext_node(1).nn=11
ext_apl(1).nn=11
ext_apl(1).an=5
9.5. Networks of interconnected NETs

This section describes how to connect the NETs and base systems into a network.
This means that several communication units - DCP-NETs and PC-NETs - may be
connected in series. For performance reasons, generally, there should not be more
than three communication units in series between a base system and a
communicating device - base system, workstation, printer or RTU. When
communication units and base systems are connected to a network, each NET unit
and each base system in the network must be defined as a node in each other’s NET
unit and base system.
The configuration described in this section is illustrated with an example in
Fig. 9.5.-1.
Communication units connected in series
Section 9.3 described how to achieve intercommunication between the
communication units within a communication frontend (rarely needed). This is the
only case where the communication link between two communication units is not a
serial lines. In all other cases, the communication goes via serial lines.
In order to connect two communication units through serial lines (e.g. NET unit 2
and 3 in Fig. 9.5.-1) 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, see Section 15.1
69
MI = System message object address, see Section 15.1

BR = Baud rate
PY = Parity
SB = Number of stop bits
RD = Read data bits
TD = Transmission data bits
ER = Embedded response
RE = Redundancy
TI = Time-out length in seconds (1 + 2400/BR)
NA = NAK limit
EN = ENQ limit
PS = Buffer pool size, see Section 9.1
The communication attributes (BR, etc.) should have the same values as the
corresponding 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
communication unit:
Device type= NOD
Device number= The node number of the connected communication unit
LI, Line number= The number of the selected line
SA = Station address of the connected communication unit
Though two communication units are connected indirectly via another unit (e.g.
communication units 1 and 3 in Fig. 9.5.-1), they must 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
communication 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
Base systems connected to the network
Each NET unit which is connected to a base system via one or more other units (e.g.
NET unit 3 and base system 1 in Fig. 9.5.-1) must 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') must be the same as the node
number of the communication unit. The NOD object is given the following
attribute values (Object Description, Section 12.8.):
70
LI = Link number (= LIN object number)

This is the link to the nearest communication unit
SA = Station address of the indirectly connected
communication units
Even if there will be no communication between the base system and the indirectly
connected NET, the node definition is necessary for the system diagnostics, on-line
configuration and system maintenance.
Correspondingly, each base system connected to a NET unit indirectly via other
units must be defined to the NET unit as a node (e.g. base system 1 and NET 3 in
Fig. 9.5.-1):
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 as described in Section 9.1.
Example
Fig. 9.5.-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.
71
Network of Base Systems and Frontends

See figure of base system with PC-NET.
Link 1
Base System 1 Communication frontend
Station Address: 209 Station Address: 206
Communication Unit 1 Communication Unit 2
Apl1 Station Address: 201 Station Address: 202
Serial lines 12345678 12345678
Base System 3
Node Number: 3
Basys_Nets_Frontends2.eps
Fig. 9.5.-1 An example of a configuration with interconnected base systems and

NETs
Configuration of Communication Unit 1
See Fig. 9.3.-1

Extermal 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
See Fig. 9.3.-1

Line 2 (ACP line)
PO Protocol: 1
IU In Use: 1
72
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
Extermal Node 3 (Communication Unit 3)
Device Type: NOD
Device Number: 3
LI Line Number: 2
IU In Use: 1
Device Type: NOD
Device Number: 9
LI Line Number: 13
IU In Use: 1
Device Type: NOD
Device Number: 11
LI Line Number: 2
IU In Use: 1
Application 1
Device Type: APL
Device Number: 1
Node Number: 9
IU In Use: 1
SW Reply Timeout: 5
Application 5
Device Type: APL
73
Device Number: 5
Node Number: 11
IU In Use: 1
SW Reply Timeout: 5
See Fig. 9.3.-1

Line 3 (ACP line)
PO Protocol: 1
IU In Use: 1
MI Message Ident.; 303
LT Link Type: 1
BR Baud Rate: 9600
SB Stop Bits: 1
PY Parity: 2
RE Redundancy: 2
NA NAK Limit: 3
EN ENQ Limit: 3
External Node 2 (=Communication Unit 2)

Device Type: NOD
Device Number: 2
LI Line Number: 3
IU In Use: 1
External Node 9 (= Base System 1)
Device Type: NOD
Device Number: 9
LI Line Number: 13
IU In Use: 1
Application 1
Device Type: APL
Device Number: 1
74
Node Number: 9
IU In Use: 1
SW Reply Timeout: 5
Application 5
Device Type: APL
Device Number: 5
Node Number: 11
IU In Use: 1
SW Reply Timeout: 5
Configuration of base system

(See Figure 6.2.-1 on page 46.)
Link 1 (LAN link):
#CREATE LIN:V = LIST(LT = “LAN”,-
TR = “TCPIP”)
……………….
Node 1 and 2
(Communication units 1 and 2):
See Fig. 9.4.-1.
………………….
Node 3 (Communication unit 3)
#CREATE NOD:V = LIST(LI = 1,-
RN = 6,-
SA = 203)
………………….
Node 11 (Base system 3):
RN = 6,-
SA = 211)
SA = 206)
Configuration of base system 3

…………………see Chapter 6
Link 1 (Intergrated link):

Configured with the System Configuration Tool
Node 2 (Communication unit 2):

SA = 202)
Node 3 (Communication unit 3):

SA = 203)
Node 9 (Base system 1):

75
RN = 3,-
SA = 209)
Frontend configuration file, MFLCONF.DAT:

SRCNOD 6
SRC 206
PROT1 2
DST1 209
HOST1 90.0.1.124
76
10. Operator workstations

This chapter describes how to configure the MicroSCADA operator workstations:
the base system operator workstations and the remote workstations that are based on
X software or Windows Terminal Server.
General
When the operator wishes to supervise an application on his or her monitor screen,
s/he opens a MicroSCADA monitor. The operator can open the monitor using a
standard dialog or a customized icon, or monitors can be opened automatically at
application start-up. When opening a monitor using the standard icon, the operator
can select the MicroSCADA monitor number, the application number and picture
size. S/he can also select the base system s/he wishes to view. The same parameters
are chosen when opening a monitor with a command.
A display can show several monitors connected to one or more MicroSCADA
applications in the same base system or in separate ones.
Windows terminal server support
It is possible to do remote administration of the MicroSCADA base system machine
from a NT Workstation. By opening a Terminal Server client window it is possible
to directly access the desktop and tools of the server machine and thus make all
administration that is needed.

Each MicroSCADA monitor must be defined as a MON object in the connected base
system. In addition, the MON objects must be mapped for the applications, which
will use them. The monitor objects are defined equally whether they will be opened
on the base system monitor or on a workstation. Fig. 10.-1 shows an example of a
workstation with three MicroSCADA 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 MicroSCADA application monitor that
will be opened on the base system monitor or on connected workstations, see
Chapter 7. Assign the MON objects the following attributes:
DT = “VS” or “X”.
Define the monitor as “VS” type, unless it should be able to
show Motif widgets
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 using freely chosen monitor numbers as indexes.
Example:
APL1:BMO(1..5) = (-1,-1,-1,-1,-1)
means that monitor numbers 1 ... 5 can be opened to view application 1.
77
Workstation
MON
MON
MON
LAN
Basesystem 1 Basesystem 2
APL1 APL2 APL3 APL4
Configuration of basesystem 1: Configuration of basesystem 2:

Monitors: Monitors:
#LOOP_WITH I = 1..20 #LOOP_WITH I = 1..20
#CREATE MON I :B = LIST(- #CREATE MON I :B = LIST(-
DT = VS ,- DT = VS ,-
TT = LOCAL = TT = LOCAL =
#LOOP_END #LOOP_END
Application 1: Application 3:
@MON_MAP(1..20) = -1 @MON_MAP(1..20) = -1
#CREATE APL:V = LIST (- #CREATE APL:V = LIST (-
.... ....
MO=%MON_MAP MO=%MON_MAP
.... ....
#CREATE APL1:B = %APL #CREATE APL3:B = %APL
Application 2: Application 4:
@MON_MAP(1..20) = -1 @MON_MAP(1..20) = -1
#CREATE APL:V = LIST(- #CREATE APL:V = LIST(-
.... ....
MO=%MON_MAP MO=%MON_MAP
.... ....
#CREATE APL2:B = %APL #CREATE APL4:B = %APL
Config_two_base.eps
Fig. 10.-1An example of a workstation that is connected to two base systems and
four applications
78
11. Peripherals
This chapter describes how to configure MicroSCADA for various peripheral
equipment:
11.1 Printers: printers connected to a base system computer, to LAN and to
a NET.
11.2 Other peripherals: alarm units and external clocks.
11.1. Printers
This section describes the configuration of printers used by MicroSCADA
applications: printers for automatic continuous event and alarm printout, for
hardcopy of MicroSCADA pictures, for printout of picture based reports, etc. For
hardcopy, the hardcopy functions of eXceed or Windows can be used without any
configuration measures in MicroSCADA.
A MicroSCADA printer can be connected as follows:
• Directly to a base system computer or another Windows computer on the
network, through the parallel port or a serial port.
• To a LAN via a printer server.
• To a DCP - NET.
Printers connected to a NET can be made accessible to all base systems in the entire
distributed MicroSCADA system. A printer connected directly to a base system can
also be used by other base systems on the LAN, provided that the printer is defined
as “shared” in the operating system configuration of the computer to which it is
directly connected. Printers connected to a LAN can be made accessible to all base
systems on the LAN.
On the application level, the printing can be accomplished according to two different
principles which determine the appearance of the printout:
• Semi-graphic picture based printing
• Full graphic SCIL defined printing ("transparent" printing)
The full-graphic printout may contain any characters supported by the printer. The
last mentioned type is specified by the SCIL function PRINT_TRANSPARENT.
The semi-graphic printout may be of three types:
• Black-and-white, character-based printout
• Black-and-white, pixel-based printout
• Color, pixel-based printout
The picture based printout produced by printers connected to a Windows computer
or a LAN is always semi-graphic. Pixel based printout can be obtained only on
printers connected to a NET. The “transparent” printout can be obtained on any
printers.
Each base system and each application is able to recognise and use up to 20 printers.
It is possible to configure “virtual printers” without real physical correspondence for
logging in a file on disk. When a printer is defined for printer logging, all printout
sent to the printer is stored on a disk. This is useful when configuring an "event log",
79
i.e. a disk copy of the event list. A physical printer may also be given more than one
printer object definitions to enable several different types of printout to the same
printer.
The printer operation can be supervized and controlled, e.g. temporarily stopped and
restarted, or the printout can be redirected to another printer. This can be done by
means of the ST and CL attributes (see the System Objects manual, Section 10.2.)
Printers connected to a Windows computer or LAN
Printers connected to a base system computer or LAN must be configured in all base
systems that will use the printers, see the example in Fig. 11.1.-2. Configure the
printer in each base system as follows:
1. Create a PRIn:B base system object, with at least the following attributes (see
System Objects, Section 12.6.):
DT “NORMAL” (black-and-white ASCII based printout) or
“TRANSPARENT” (SCIL defined printout)
DC “LINE”
SD Printer device name including UNC path
(SD="\\My_Computer\My_printer"). The printer must be shared
for the UNC name to be a valid value of the attribute.
TT "LOCAL”
In addition, optional features are defined by the following attributes:
LP Lines per page, this should be > = the number set on the printer
QM Printer queue length
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”
OJ Open on Job Basis, set value to 1
The printer is opened before each print job and closed when the
job is completed
2. If needed, map the printer for an application with the APLn:BPR attribute, see
"Device Mapping" in Section 6.1. 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.
80
Fig. 11.1.-1 An example of a configuration where a printer is connected directly to

a base system
Printers connected to NETs

A printer connected to a NET can be used by all base systems connected to the same
network of frontends. The printer must be defined both in the base systems which
will use it and in the NET unit to which it is directly connected, see the example in
Fig. 11.1.-2. It is here assumed that the 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
81
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 "TRANSPARENT", 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 the System Objects
manual, Section 10.2.
2. If needed, map the printer for an application with the APLn:BPR attribute, see
"Device Mapping" in Section 6.1. 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.
82
Include the following definitions in the NET unit to which the printer is directly
connected:
Printer connected to the Process Communication System
Base system 1 Base system 2

Apl1 Apl2 Apl3 Apl4
Frontend
NET 1 NET 2
Node number: 1 Node number: 2
Station address: 201 Station address: 202
Printer 1
PRI 1
Base system Configuration Configuration of NET 1

(in both base systems) ....
.... Line 8:
Node: PO Protocol: 4
See chapter 8 IU In Use: 1
..... MS Message Application : 1
Printer 1 MI Message Ident : 6104
#CREATE PRI:V BR Baud Rate: 2400
#SET PRI:VDC = NET SB Stop Bits : 1
#SET PRI:VDT = COLOR PY Parity : 0
#SET PRI:VND = 2 RD Receiver Data Bits : 8
#SET PRI:VTN = 1 TD Transm. Data Bits : 8
#SET PRI:VTT = LOCAL OS Output Synchroniz. : 3
#CREATE PRI1:B = %PRI TI Timeout Lenght : 10
PS Buffer Pool Size : 16
Color Printer = Printer 1:

Device Type : PRI
Physical Device Number : 1
LI Line Number : 8
AL Allocation : 0
AS Allocation Applic. : 0
IU In Use : 1
MI Message Ident. : 3001
MS Message Application : 1
PT Printer Type : 5
Pri&Process_Comm_Sys.eps
Fig. 11.1.-2 The configuration of a printer connected to the process

communication system
83
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 Section 9.2
BR Baud rate (recommended value 2400)
PY 0
RD 8
SB 1
TD 8
OS Output synchronization, see the System Objects manual,
Chapter 13
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, see Section 15.1
AL, AS 0 (the printer reservation is handled automatically 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 characters
6 = Facit 4544
7 = pixel-based, color
For more information on the attributes of the PRI object, see the System Objects
manual, Chapters 12 and 15.
In some cases, the printout from a printer connected to frontends can be improved
with some system object attributes. These attributes can be applied during operation,
not in the reconfiguration:
• If the printer is color and pixel based, the colors can be converted from screen
colors to printer colors with the PRIn:SCC attribute.
• If the printer is of type 5 (PT = 5), the MicroSCADA characters can be exchanged
to appropriate printer characters by means of the PRIn:SCT attribute.
• For pixel printers, each character can be specified separately by a bit pattern with
the PRIn:SPX attribute.
The three attributes mentioned can be found in the System Objects manual, Chapter
15.
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.
84
11.2. Other peripherals
Alarm units
To use an alarm unit for audio-visual alarms:
1. Set the SYS:BAA attribute in the base system configuration to any value <> 0,
e.g. 1.
Example:
#CREATE SYS:V.......
#SET SYS:BAA = 1
.......
2. Set the SYS:BAD attribute in the base system configuration to be either

“NUDAQ PCI-7250” or “Advantech PCI-1760”. This attribute is necessary
only for the PCI based alarm panel. When using the ISA based panel, it can be
omitted. For more information about the SYS:BAA and SYS:BAD attributes,
see Chapter 4 in the System Objects manual.
The alarm unit works only for process objects with a logical printer
connection (defined in the process database, see the Application
Objects manual, Chapter 3).
The following executable syntax can be applied, when the alarm unit is used.
AUDIO_SET ALARM_CLASS [on | off]
Enables setting alarms on or off manually when using the ISA based Flytech card
and the compatible alarm panel.
'alarm_class' The number of alarm class. Integer expression, 1 … 7, or all
'on | off' Alarm(s) can be set on or off. If neither of these values is given,
alarm(s) will be set off by default
Audio_set can be called by using ops_call, ops_process or it can be called directly
from the command line (or called from batch file). The caller receives a return value
from audio_set, which can be used to determine whether the command was
successful or not. Return value 0 means that the execution was successful and any
other value means that an error happened during the execution. When audio_set is
run from the command line, possible error messages are shown in the workstation.
These are of course not seen if ops_call or ops_process are used.
The user should notice that when ops_call and ops_process are used, the commands
should be given so that they wait that the execution of audio_set is finished. If they
do not wait, they cannot get the return value returned by audio_set. More details
from using these SCIL commands can be found from the Programming Language
SCIL manual. The user should also notice that when audio_set is used from the
command line, the user should take care of the return value of audio_set (it cannot
be seen automatically).
Examples:
;; Set alarm 1 on from SCIL
@a = ops_call("c:\sc\prog\exec\audio_set 1 on")
;; Set all alarms off from SCIL
85
@a = ops_process("c:\sc\prog\exec\audio_set.exe all off", "", "wait")
;; This is given from the command line and it sets alarm 1 off
audio_set 1
External clocks
To use a Meinberg PC31 radio clock in the base system:
1. Set the SYS:BCL attribute to "PC31" and the CA attribute to any value <> 0,
e.g. 1.
Example:
#CREATE SYS:V
.......
#SET SYS:BCL = "PC31"
#SET SYS:BCA = 1
.......
To connect an external clock to a communication frontend:

2. Specify the following parameters in the MFLCONF.DAT file (see Section 5.2.):
COMAG 1 (use COM port 1)
CLOCK The type of the clock
Serial communication parameters: BR, COM, EN, ER, NA, PY, RE, TI.
To connect an external clock to a communication unit:
3. Define a NET line with the following attributes:
PO 15 (General ASCII protocol)
PM 5 (Protocol mode)
SF Syncronization format
1 = COMPUTIME
2 = RCC8000
86
12. Configuring stations

This chapter describes the general principles for configuring stations in
MicroSCADA and it provides some system configuration notes related to certain
station types. This chapter contains the following sections:
12.1 General principles for configuring stations in MicroSCADA.
12.2 Configuration notes for stations using the ANSI X3.28/A-B protocol:
SRIO, Allen Bradley PLC and SLC-500, Westronic D20, DTU, etc.
The configuration is illustrated with an example. Configuration of
SRIO from MicroSCADA: SRIO system parameters for affecting the
behaviour of SRIO, e.g. the spontaneous transmission of data, polling
interval and data format, and SRIO object parameters for the definition
and modification of SRIO objects. The description is valid also for
SPSC500, though this station type is mentioned only where it differs
from SRIO.
12.3 Configuration notes related to S.P.I.D.E.R. RTUs. The configuration of
MicroSCADA for S.P.I.D.E.R. RTU 200: base system configuration
and NET unit configuration. The configuration is illustrated with an
example. Building the RTU configuration files for use in
MicroSCADA and for transfer to the RTUs via MicroSCADA.
12.4 Stations in the LONWORKS network; Stations supported by the System
Configuration Tool and protocols supported by the PC-NET;
Configuring the LONWORKS network.
12.1. General principles
Stations
The following instructions are not valid when using the System
Configuration Tool, which is decribed in Chapter 16.
All process devices that will exchange information with MicroSCADA are regarded
as stations and must be defined as station objects both in the process communication
system (NETs) and in the base systems. The concept station comprises RTUs, PLCs
and bay units of various types. It also comprises protocol converters and control
centres which are connected to the NET for data transfer between MicroSCADA and
external devices. However, it does not comprise e.g. the star couplers situated in the
LONWORKS network, as they have no direct data communication with
MicroSCADA.
This section presents the general configuration requirements for connecting stations
to MicroSCADA.

Connecting a station to the MicroSCADA network requires the following
definitions in the base system that will use the station (see the example in
Fig. 12.2.1.-2):
87
1. 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 = The station type
TN = STA object number in the communication unit
TT = "EXTERNAL"
The STAn:B object definition is not necessary if the default station type, defined by
SYS:BDS, is the station type in question and the default node, defined by
SYS:BDN, is the NET unit to which the station is connected and mapping of the
stations is direct (1-1, 2-2 etc.). It is, however, always recommended that the object
definition is made.
2. If needed, map the station for the application which will use it with the
APLn:BST attribute. Station mapping is necessary only if the logical number
will be 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. See the System Objects manual, Chapter 5.

Perform the configuration definitions described below in the communication unit to
which the station is directly connected. The station address (SA for the others and
SX for ANSI X3.28 stations) of this unit should be the same as the "destination
address" defined in the station. 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, see Chapter 9. Define the station to the NET unit
as follows (see the example in Fig. 12.2.1.-2):
1. Select a line for the station and define it with the protocol that will be used on
the line:
PO Number of line protocol
If the NET is a PC-NET, the COM ports (1...4) or the “RocketPort” ports (1...8)
(NET lines 1...4 and 1 ... 8) can be used for process communication using the SPA,
IEC60870-5-101 master and slave, IEC60870-5-103 master, IEC1107, ADLP80
slave, RP 570 master and slave, RP 571 master and LCU 500 protocols. When
assigning one of the lines 1 ... 12 any of these protocols, the lines will be reserved
for process communication. The used NET line number cannot be used for
LONWORKS communication.
2. Depending on the protocol, assign the line appropriate attributes.
3. Define the station of the type in question and assign it the desired attributes.
4. Make sure that the application which will receive the spontaneous messages
from the station (the station attribute AS) is defined as an APL object. See
Chapter 9.
88
12.2. Stations using ANSI X3.28 protocol
12.2.1. MicroSCADA configuration

Connecting a station using the ANSI X3.28 protocol (ANSI station) to the
MicroSCADA network requires the following definitions in the base system which
will use the station (see the example in Fig. 12.2.1.-2):
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 and the mapping is direct.
If needed, map the station for the application which will use it with the APLn:BST
attribute. Station mapping is necessary only if the logical number will be 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 (see the System Objects manual, Section 15.2).

Perform the configuration definitions described below in the communication unit to
which the station is directly connected. The SX attribute of this unit should be the
same as the "destination address" defined in the ANSI station. 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, see Chapter 9.
Define the station to the NET unit as follows (see the example in Fig. 12.2.1.-2):
1. Select a line for the station and define it with the ANSI X3.28 full duplex
(possible for communication with Allen-Bradley, Westronic, SRIO) or half
duplex protocol:
If ANSI X3.28 full duplex is used:
PO = 1
LT = 0 (RS232), 1 (modem line), 6 or 7
IU = 1
EN = Enquiry limit
TI = Timeout length in seconds
ER = Embedded response, see Section 4.2.4. in the SystemObjects manual
NA = NAK limit
If ANSI Half Duplex is used:
PO 2
89
LT 0 (RS232), 1 (modem line), 2, 3, 4, 6, 7 or 8

IU 1
TI Timeout length in seconds: 1 + 2400/BR
EN Enquiry limit (max. number of retries): the product
TI * EN must be << the RT attribute of the station, see
below
RE = Redundancy
0 = none
1 = CRC
2 = BCC
DE = CTS delay, see Fig. 12.2.1.-1.
HT = Header Timeout
Default = 700 msec
PD = Extra poll delay
Decreases the load on NET, but can be set to 0
PP = Polling Period
Regulates the polling frequency of operating stations
related to suspended stations. Note that each polling of a
suspended station is likely to cause a timeout on the line.
RK = RTS Keep up padding characters, see Fig. 12.2.1.-1
Necessary with some modems
RP = Reply poll count
The following attributes apply to both ANSI X3.28 Full and Half Duplex:
BR = Baud Rate
This must be the same as the baud rateset in the station
PY = Parity
0 = none
1 = odd
2 = even
This must be the same as the parity in the station
RD = 8
SB = 1
TD = 8
RE = Redundancy (0 = none, 1 = CRC, 2 = BCC)
Chapter 9.
3. Define a station of type STA connected to the ANSI line:
Device type:STA or 3
LI Selected line
AL 1
AS The number of the connected application
IU 1
MS System message application, see Section 15.1.
90
MI System message identification; use as a process

object address, see Section 15.1.
SA = ANSI station address = the address given in the station
DE = Type of diagnostic commands (0 = none)
DI = Diagnostic interval in seconds
FS = Type of commands allowed during suspension (0 = none)
RT = Reply timeout in seconds
SP = Message split, see below
ST = 1 for all types except for SLC-500 which is = 4
SU = Suspension time in seconds
If more stations are connected to the same line, they are defined in the same way and
with the same line number.
4. Define the memory areas in the NET unit and Message Split if needed, see
‘Memory area definitions’ and ‘Message split’ below. In the preconfiguration,
these features are found under the "Memory Rung", where up to 80 memory
areas can be defined. If the preconfiguration tool is used, the memory area
definitions of a STA can be collectively copied to other STAs and then possibly
edited. If there are many stations, the memory area definitions are most
conveniently added on-line with SCIL command procedures by using the MR or
MC attributes, see the example in Fig. 12.2.1.-2 and the System Objects manual,
Section 4.3.6. By means of the MC attribute the memory area definitions can be
copied collectively on-line from a station to another.
The SX attribute of the NET must be given as the destination address

for spontaneous messages in the station configuration.
91
ER - Embedded Response
Message
ER = 1: DLE STX Data DLE STX Data DLE STX
DE - CTS Delay
RTS
CTS
DE=0: Data
DE>0: Data
RK - RTS Keep Up Padding Characters
RK = 3: Data NUL NUL NUL
ANSI_line_attr.eps
Fig. 12.2.1.-1 Illustrations of some ANSI line attributes
Memory area definitions

The internal protocol used in the communication between base systems and the NET
differs from the protocol used in the communication between NET and the stations.
Often, the data related to different memory areas of a station must be coded in
different ways (e.g. some 4-digit BCD, some 16-bit words). The Allen-Bradley /
ANSI X3.28 protocol does not include this coding information in the commands.
Therefore, NET needs the memory area definitions to know how to handle a certain
message data.
Each memory area is identified by a number, 1 ... 30, and defined by the following
attributes (System Objects, Section 4.3.6):
DT Data type of the area
AD Start address of the area
LE Length of the area
CO Data coding
AT The write access to the area
BF Block format
TS Time stamping
SP Split destination, see below
The required memory area definitions depend on the station type. Table 12.2.1-2
shows the memory area definitions needed for the SRIO communication. If no SRIO
feature is used, the corresponding area may be omitted. Sequential BI and BO areas
92
may be combined into a BO area, and correspondingly sequential AI and AO areas

may be combined into AO areas, if the same coding can be used. NET allows
reading the output areas, but not writing to the input areas. Analog access to binary
areas is allowed, but not bit access to analog areas. The diagnostic counters (start
address 4704 octal, length 26 words) need not to be defined as a separate memory
area, because it is always possible to read 16-bit analog values outside the memory
areas.
For SRIO 1000M (V6.0 or newer) the EV data must be defined as a separate memory
area. The recommended start address for this area is 750 decimal. Thus the DO area
is shorter than in SPSC 500M.
Example
Fig. 12.2.1.-2 shows an example of an ANSI station connected to line 1 of NET3.
The table below lists the configuration of the NET and the base system.
Base System 3
Node number: 3
STA4
Station Address: 72
Basys&Sta.eps
Fig. 12.2.1.-2 An example of a configuration with a base system connected to a

station using the ANSI X3.28 Full Duplex protocol
Table 12.2.1-1 Communication unit configuration (Stations Using ANSI X3.28
Protocol)
Communication Unit Configuration
Line 1
PO Protocol: 1
IU In Use: 1
MI Message Ident.: 6301
LT Link Type: 0
BR Baud Rate: 9600
SB Stop Bits: 1
PY Parity: 2
93

RE Redundancy: 2
NA NAK Limit: 3
EN ENQ Limit: 3
Process Unit 4/20

Device Type: STA
Physical Device Number: 4
LI Line Number: 1
AL Allocation: 1
AS Allocating Application 5
SA Station Addr. (Dec) 72
DE Diagnostic Enable: 0
DI Diagnostic Interval 0
FS Fast Sel. to Susp.: 0
RT Reply Timeout: 20
SP Message Split: 0
Base System Configuration

#CREATE STA:V = LIST(-
ST = “STA”,-
ND = 3,-
TN = 4,-
TT = “EXTERNAL”)
#CREATE STA:B = %STA
Online Definition of a Memory Area

#SET STA4:SIU = 0 ;Taking the station out of use
#SET STA4:SMR6 = “CBI” ;Memory area 6 is BI type
#SET STA4:SAS6 = 400^ ;and starts from address 400 octal
#SET STA4:SLE6 = 16 ;The length of the area
#SET STA4:SIU = 1 ;Taking the station into use
Deleting Memory Area

#SET STA4:SIU = 0
#SET STA4:SMR6 = “D”
Table 12.2.1-2 The memory area definitions needed for SRIO and SPSC500
Area Type, Length, Coding, Access, Block, Time
Address, AD
No. DT LE CO AT BF Stamping, TS
dec oct
Areas for transfer of process data:
94
1. 2 (BO) 0 0 750 3 0 1 0
2. 4 (AO) 1000 1750 1000 4 0 1 0
Area for event recording:
3. 3 (AI) 2400 4540 4 4 0 1 1
Area for transfer of parameter data:
4. 4 (AO) 2000 3720 168 10 0 1 0
Area for setting the clock:
5. 4 (AO) 2300 4374 9 5 0 1 0
System parameters areas:
6. 4 (AO) 3000 5670 6 3 0 1 0
Object parameters areas:
7. 4 (AO) 5000 11610 5500 3 0 1 0

8. 4 (AO) 10500 24404 1000 4 0 1 0
9. 4 (AO) 11500 26354 2700 3 0 1 0
10. 3 (AI) 750 1356 250 3 0 1 1
For SPSC500, differing from the above, the first memory area is defined:
1. 2 (BO) 0 0 1000 3 0 1 0
Memory area 10 is not used in SPSC500.
Message split
It is often desired that spontaneous messages from the process stations are sent to
several applications in one or several base systems. This can be established with the
Message Split feature. Message Split means that a copy of a message is sent not only
to the application defined by the AS attribute, but also to other applications. The
Message Split feature is memory area specific, i.e. the feature must be defined
individually for each memory area.
Message Split concerns exclusively the spontaneous messages from

the stations. It does not cause the copying of responses to read
messages.Thus, if the MicroSCADA databases are continuously
updated by getting the data from thestations (with the #GET
command), the Message Split functionality will not be needed.
In these cases, each application must get the data from the stations or read it from
another application (see Section 6.2).
In order to activate Message Split:
1. Make sure that all the applications to which the spontaneous messages will be
sent have been defined in the NET unit by APL objects, see Chapter 9.
2. Set the SP attribute of the station to 1, 2 or 3 (see the System Objects manual,
Section 14.3.7.).
Select receiving applications (up to five) by setting the SL attribute for the memory
area to the desired application numbers. In the preconfiguration the SL attribute is
given as a number of five digits. Therefore, only applications number 1 ... 9 can be
95
selected as receiving applications. In order to set the attribute on-line with SCIL, see
the System Objects manual, Section 14.3.7. and the example below. In the
preconfiguration, the SL attribute can be found under "Memory Rung".
Example
Taking Message Split into use on-line:
#SET STA2:SSP = 2
#SET STA2:SSL101 = 2050
#SET STA2:SSL303 = 2049
The SPLIT function is activated. An error message will be generated, if the base
system defined in the station does not answer. The messages connected to memory
area 1 are sent also to APL2. Messages connected to memory area 3 are sent also to
APL1.
12.2.2. SRIO configuration
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.
Below are some examples of system parameters, each of which occupies one word.
For further information about SRIO system parameters, refer to the SRIO manuals.
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)
Examples
#SET STA1:SME3001=0
Disable spontaneous process data transmission.

#SET STA1:SME3002=1
96
Store SRIO 1000M configuration data into EEROM memory.

#SET STA1:SME3003=1
Analog values to be coded as 3-digit BCD numbers.
SRIO object parameters

The SRIO object parameters allow the MicroSCADA 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 means the start
address within the object parameter area, i.e. add 5000 to each address):
Attribute Start address

ANSI address 0
Busnumber 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
@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
97
@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 may consist of 10 data items, and there may 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 may comprise 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:
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
Adding a SRIO object to the event data poll list
Variables:
@ENTRYNR = Nr of the event data poll list entry
@DEF ;@DEF(1) = %BUS
;@DEF(2) = %UNIT_NR
;@DEF(3) = %UNIT_TYPE
;@DEF(4) = %STATUS
98
Adding the object:

@EP_S_I = 13000
@STADR = %EP_S_I + %ENTRY_NR * 4
#SET STA1:SME(%STADR .. %STADR + 3) = %DEF (1..4)
12.3. S.P.I.D.E.R. and Collector RTUs
12.3.1. MicroSCADA configuration

Connecting a S.P.I.D.E.R. RTU to a MicroSCADA network requires the following
definitions in the base system which will use the station:
1. Create a STAn:B object with the following attributes:
ND = The node number of the NET unit to which the RTU is directly
connected.
ST = "RTU"
TN = Corresponding STA object number in the communication unit.
TT = "EXTERNAL"
For more information on the attributes, see the System Objects manual, Section
14.4.
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 tool pictures.
2. If needed, map the station for the application which will use it with the
APLn:BST attribute. Station mapping is necessary only if the logical number
will be 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. (see the System Objects manual, Chapter 5).

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 (see Chapter 9).
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, see Section 15.1.
BR = Baud rate, should be the same as in the RTU
PY = 2
RD = 8
99
TD = 8
SB = 1
PS = Buffer pool size, see Section 9.1.
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 must be used, if NET's
transmission echoes back into the receiver.
RK = RTS keep up padding characters, see the System Object
manual, Section 13.4
Chapter 9.
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, see Section 15.1.
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 will recognise 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.
Regarding communication loops, see Section 14.3.
The following RTU200 features must be handled on-line:
4. Synchronize the RTU200 clock with the clock of the NET unit at start-up by
setting the SY attribute, e.g. #SET STAn:SSY (supposing that the NET clock
has been synchronized before). By using the broadcast station number, all RTUs
connected to one NET can be synchronized simultaneously.
5. If needed, change the AW attribute of the RP 570 line (see the System Objects
manual, Section 13.5). This is normally not necessary.
100
Sub-RTUs
MicroSCADA 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 manner as an RTU connected directly to NET as described
in the manual. The only difference between the directly connected RTUs and sub-
RTUs is the STAn:SHR attribute, see the System Objects manual, Section 14.4.1.
For STA objects corresponding to sub-RTUs, the HR attribute is the station address
of the RTU one level above in the hierarchy.
Protection relay data

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 etc., 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 normal
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 etc., 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 normal
The coding of each field, when not explicitly described above, follows the RP 570
telegram.
101
12.3.2. RTU configuration
Procedure
The RTU configuration can be performed independently of MicroSCADA, which
means that the MicroSCADA process object definition is built separately with no
help from the RTU configuration files. Alternatively, the RTU configuration can be
built via MicroSCADA, which means that the MicroSCADA engineer can utilize
the configuration in the process object definitions. Changes in the MicroSCADA
process database can then be loaded down to the RTUs.
The latter configuration method, which is recommended, is performed in the
following steps (see Fig. 12.2.1.-2):
• RTU configuration tool for RTU engineering, the EDU (Engineering and
Diagnostic Unit) tool. The RTU configuration is stored in keyed files. When
using EDU, a file conversion is required.
• Defining the process database objects in the MicroSCADA system using the key
files.
• Loading down the complete configuration, including possible changes made in
the MicroSCADA process database, to the RTU.
Loading the RTU configuraiton

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.
The loading is performed in the RTU tool picture:
1. Select OTHER CHOICES.
2. Select DOWNLOAD.
3. Click START to start the loading.
12.4. Stations in the LONWORKS network

The MicroSCADA base system communicates with a LONWORKS device through
the PC-NET and a LONWORKS network interface card. The interface card can be, for
example, a PCLTA card. PC-NET is a communication software, that runs on the
main processor of a Windows computer in parallel with the base system. As
communication channels, the PC-NET software may utilise the serial line COM
ports of the PC and the optical lines of the PCLTA card.
Station types
MicroSCADA recognises the following station types in the LONWORKS network:
REx A REx station is a unit communicating with MicroSCADA with
vertical communication as defined in LON Applications Guidelines
(e.g. REF 543 protection terminal)
SPA A SPA station is a SPACOM module connected to the LONWORKS
network via a protocol converter (i.e. an LSG device)
LMK An LMK station comprises all types of devices, except SPA and REx
devices, connected to the LONWORKS network using the standard
LONWORKS interface (e.g. an LSG device or a Weidmüller I/O device)
102
Protocols supported by the PC-NET

PC-NET supports the following protocols:
• ACP (the internal protocol of MicroSCADA)
• LonTalk
• SPA
• IEC 60870-5-101 master and slave
• IEC 60870-5-103 master
• IEC 60870-5-104 master and slave (LAN)
• IEC 1107
• RP 570 master and slave
• RP 571 master
• LCU 500
• DNP 3.0 master and slave
• DNP 3.0 master and slave (LAN)
• Alpha
• Modbus master
• ANSI 3.28 Half Duplex
• Westinghouse F4F slave
Configuring the LONWORKS network

To enable communication between MicroSCADA and a station in the LONWORKS
network you must:
• Configure the device
• Configure the LONWORKS network
• Configure the PC-NET
• Configure the MicroSCADA base system
On MicroSCADA point of view the configuration is done with the System
Configuration Tool, which is described in Chapter 16. The Connecting LONWORKS
Devices to MicroSCADA manual gives more profound information on the
configuration work.
For device configuration, please refer to the specific device configuration manuals
and the LNT 505 manuals.
103
13. Mirroring
13.1. Functional overview

Process database mirroring, or just mirroring for short, provides a powerful means
for sharing process data in a MicroSCADA network with a minimal engineering
effort. Mirroring may be considered as one implementation of the client-server
model of computing. The server application, called the host, delivers process data
to one or more client applications, called images. Usually, the host and the images
are located in different computers. Local mirroring, i.e. mirroring between two
applications within a MicroSCADA computer, is also supported.
In a hierarchical MicroSCADA network, an image may act further as a host to one
or more upper level images. This is called hierarchical mirroring.
Mirroring may be used in several ways in different network configurations. Some
examples are depicted later in this chapter.
The most common use of mirroring is to build a hierarchical control system, where
several substations are connected to a network control center, each location running
a MicroSCADA system. By using hierarchical mirroring, a wider network
containing substations, regional control centers and a main control center may be
built. This use is quite close to what COM 500 is used for. However, because of a
common system architecture and a proprietary communication protocol, the
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, without any application level SCIL
programming.
Within a substation, one SYS 500 MicroSCADA system may replace the pair of
SYS 500 and COM 500 systems previously often required to control and supervise
the substation. Even if a COM 500 is needed to communicate with a non-
MicroSCADA network control center, the sharing of process data between the
COM 500 and the SYS 500 may be done by mirroring. In this case, the SYS 500 and
COM 500 may run as separate applications in one computer.
Mirroring may even be used to share process data among totally different kinds of
applications. For example, electrical SCADA and district heating SCADA may
share some indications, measurements and events. In this case, both applications
may act in double roles, both as a host and as an image.
13.2. Technical overview

Mirroring is defined on station (STA:B) object level: A station in the SYS 500 that
is connected to the PC-NET, the host station, is connected to one or more image
stations located in other applications usually in other MicroSCADA machines. One
host station may have up to 10 image stations. In a hierarchical mirroring system,
each image station may 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 is
defined by some new station object attributes.
105
The application containing the host station, is called the 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 may have both host
and image stations, so it may 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: If the object address (OA and OB) 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 may 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 may contain only a subset of addresses found in the
host database, the uninteresting signals may be dropped from the communication
load.
The mirroring functionality contains the following sub-functions:
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 may 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, the switch-overs are handled
automatically with no events lost.
Mirroring may be disabled/enabled on a host/image application pair basis by setting
new APL object attributes. While the mirroring is disabled, the host buffers events
just like 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.
106
Because it is possible to create very large image applications using the mirroring
functionality, the maximum number of STA base system objects
(MAX_STATION_NUMBER in SCIL) has been increased from 2000 to 5000.
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.
• MR = "BOTH": This is an image station that receives the process data from the
host station defined by the attribute HS. Furthermore, it itself 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 two 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 to be 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
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 may be dropped, see ‘Buffering and communication breaks’ below for
details. In a hierarchical mirroring network, the image application may 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, i.e. 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 using the following notation:
#SET ABC:P1 = LIST(OV = 1, SU = 1)
Process commands
Process commands, i.e. #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
107
successful, the new OV value is distributed as a mirroring event to the host database
and all the 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.
System object (STA:S) communication
Evaluation of STA:S object attributes in an image application, as well as the SET
command (#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 application. 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.
System Messages
System messages from the NET are delivered to image applications in a way very
similar to process messages. There is a slight difference in configuration due to the
fact 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 the case of 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 exactly 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 are to 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.
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, i.e.: the addresses
that
• Are in use
• Are in AUTO switch state
• Belong to a unit (station) that is connected to the host
108
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
automatically 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 may then
decide to subscribe to its events.
The database of the image application may be only a subset of the host database, thus
reducing the required communication rate.
Each image application does its own subscription. The subscriptions may be
different.
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 of the application (Event Queue Length Maximum) 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:
• 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 may be lost.
• EP = "KEEP": The events are not allowed to be lost. In this case, the process
communication between the host application and PC-NET will be slowed down
just as if the EU attribute of the host application would have reached EM.
The "KEEP" policy is obeyed 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
109
sends the sequence number of the last received message to the host and requests
retransmitting of newer events. If the host still have the requested events in its
buffer, it sends them and no events have been lost.
If the requested events are no longer available (because of queue length having
reached its maximum during the break or the host has been down), the image
application will do a new subscription and events may 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. The term ‘measurement event’ here means a process message to an analog
input process object when all the following 3 conditions are met:
1. The object has a real value representation. Integer valued AI objects, i.e. the
ones with IR = 1, are not considered as measurements.
2. The event is a measurement event according to the load control policy of the
station, see below.
3. The object address is not included in the list of analog event addresses (attribute
AE) of the station, see below.
The rate of measurement events is reduced by the following two rules:
1. A measurement event is not sent if there is an event with the same value in the
queue already.
2. If there are two measurement events for the same object in the queue and a third
one is coming, the second one is discarded provided that the AZ (Alarm Zone)
attribute of all the three events is equal.
The LP (Load Control Policy) attribute of the station (STA:B) object defines which
analog events may be considered as ‘measurement events’ in the sense described
above. The attribute may take one of the following four values:
"KEEP_ALL_ANALOGS" No analog messages are taken as

measurements.
"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
measurements whether time-stamped or
not.
"DEFAULT" The LP attribute of the corresponding
STY object is applied.
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 the System Objects manual.
110
The AE (Analog Events) attribute of the station (STA:B) object is defined in the host
system. Its value is an integer vector of any length and it contains a list of the analog
input object addresses (OA) within the station that are not to be taken as
‘measurements’ in the sense described above.
Hot stand-by
HSB switch-overs are automatically taken care of, no SCIL command procedures
are involved.
To be able to do this, the base system must know which external applications make
up an HSB pair. Therefore, the SN (Shadowing Number) attribute of the external
applications that participate in mirroring must be set. Either of the two applications
numbers may be given as the APL attribute of the HS or IS attribute of the stations
participating in the mirroring.
For example, if in an image system, external host applications 7 and 8 make up an
HSB pair, the SN attribute of APL7 must be set to 8 and the SN attribute of APL8
must be set to 7. Either 7 or 8 may 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 switch-over of the host or the image application, the image application asks the
host to retransmit all the events newer than the last received event.
Disabling mirroring
In an image system, the mirroring communication with a particular host application
may be temporarily disabled by setting the HE (Host Enabled) attribute of the APL
object of the host 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
may be temporarily disabled by setting the IE (Image Enabled) attribute of the APL
object of the image to 0. Mirroring is re-enabled by setting the attribute back to 1.
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
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 the Application Objects manual, Predefined
application event channels.
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.
111
The events reported by the event channel in the image application are the following:
Source Event Description
“UN” “MISSING” The connection to the host station cannot be

established, because of a mismatch in STA object
configuration between the image and the host.
“LOST” The connection to the host station is lost, because the
mirroring configuration (either MR or IS) in the host has
been changed
“FOUND” The connection to the host station 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 generated instead
of the "LOST" unit to tell the application, that there is
nothing wrong with the mirroring configuration between
this application and the intermediate level application,
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.
“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 doing
shutdown.
“DISABLED” The communication with the host has been disabled by
setting APL:BHE to 0.
“ENABLED” The communication with the host has been enabled by
setting 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:
“IMAGE” “CONNECTED” The connection to the image is established.

“LOST” The connection to the image is lost.
“DISCONNECTED” The image application has disconnected the mirroring
session.
“RECONNECTED” The connection to the image is re-established without
losing any events.
112
“OVERFLOW” The event buffer for the image has overflown. Events
have been lost.
“BLOCKING” The event buffer for the image have become 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
connection does not slow down the communication
between the SYS and the NETanymore. 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).
Diagnostics
Two diagnostic attributes of (external) application objects count various events in
the mirroring communication.
The HD (Host Diagnostics) attribute is a 10-element vector that, in an image system,
contains the following counters for the mirroring communication with the host
application:
Index Host Diagnostics Counter

1 Received events
2 Received event messages
3 Transmitted process object commands
4 Transmitted STA:S commands
5 Established connections
6 Connection breaks
7 Successful reconnections after a break
8 Stations currently mirrored
9 Addresses currently subscribed to
10 Missing addresses
113
The ID (Image Diagnostics) attribute is a 10-element vector that, in a host system,

contains the following counters for the mirroring communication with the image
application:
Index Image Diagnostics Counter

1 Transmitted events
2 Transmitted event messages
3 Received process object commands
4 Not used, always 0
5 Established connections
6 Connection breaks
7 Successful reconnections after a break
8 Stations currently mirrored
9 Addresses currently subscribed to
10 Missing addresses
The elements 8 to 10 of both attributes are counted down when a mirroring session
is disconnected.The others are cleared only by explicitly doing so though a SCIL
program.
13.3. Configuration
The configuration of a mirroring system is quite a straightforward task. The main
steps of the mirroring configuration procedure are the following:
• Create a node for each base system in the mirroring system (and a LAN link).
• Create an external application for each image in the host system and an external
application for each host in the image system.
• 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.
• 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 pretty low compared to finding out the smallest usable value. If, for a
reason or another, a lower value is preferred, the following rule-of-thumb 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.
• 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.
Three 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. The usage of station mapping is
demonstrated in case 3.
114
13.3.1. Example 1. One host, one image
mir_1.bmp
Fig. 13.3.1.-1 A simple mirroring system

This is the basic case. Process database events of a host base system are mirrored to
an image base system.
Host
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)
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 then the mirroring
attributes can be defined in SYS_BASCON.COM. The definition must be done for
each mirroring station; the definitions for unit 51 as an example in the following.
115
#SET STA51:BMR = “HOST“

#SET STA51:BIS = VECTOR(LIST(APL=2, UN=51))
The host application is connected to one image application, so there shall be at least
two APL-APL servers.
#SET APL1:BAA = 2
Now the host part of the mirroring configuration is ready. The image system
configuration is described in the following.
Image
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:

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, here 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
Now the configuration of the image system is ready. Both base systems can now be
started and the process objects which are of interest shall be 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 must 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, must be created to
receive system messages from the host.
#CREATE STA91:B = LIST(-
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 will be delivered to the image application.
116
13.3.2. Example 2. Two hosts, redundant image
Fig. 13.3.2.-1 Redundant image, two hosts

In this example a redundant image base system receives process updates from two
host base systems.
• 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.
Hosts
The base system nodes for the image base systems are required and must 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 shall 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 external applications
2 and 3 make up a HSB pair.
117

NA = “IMAGE1“,-
ND = 228,-
SN = 3,- ;Shadowing partner
TN = 1)

NA = “IMAGE2“,-
ND = 229,-
SN = 2,- ;Shadowing partner
TN = 1)
of the net node. If the system configuration tool is not used then the mirroring
attributes can be defined in SYS_BASCON.COM. The definition must be done for
each mirroring station; below an example of the definitions for unit 51:
The host application serves one image application, so there shall be at least two
APL-APL servers.
#SET APL1:BAA = 2
Now the mirroring configuration of the hosts is completed.

Redundant Image
The mirroring configuration of the redundant image base system is described in the
following. It is reasonable to make the modifications in one configuration file and
then copy the results to the configuration file of the redundant base system.
A node shall 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 shall be created for each host base system.

NA = “HOST1“,-
ND = 232,-
TN = 1)

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
118
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.

The image application receives messages from two hosts, so there shall 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
In a mirroring system where process events are gathered from several existing hosts
it is possible, even probable, that the same unit number exists in several hosts. Thus
after the process objects have been copied the overlapping unit numbers must be
changed in the image application. In the host base system this must be noticed when
defining mirroring attributes for the station. For example if unit 2 exists both in host
1 and host 2, the unit number of the process objects from host 2 must 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 shall then be
in host 1 and
#SET STA2:BMR = "HOST"
in host 2.
In the image base system a new STA object, station 3, must be created with the
appropriate mirroring attribute values:
#CREATE STA3:B = LIST(-
ST = “RTU“,-
MR = “IMAGE“,-
HS = LIST(APL=6, UN=2)
TN = 3)
13.3.3. Example 3. Station mapping 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
several applications in an image base system. Station mapping feature is required in
such a configuration.
119
Fig. 13.3.3.-1 The same unit number in two image applications

The mirroring configuration procedure is the same as in the previous examples.
Hosts
Mirroring related configurations for host 1.
#CREATE NOD228:B = LIST(- ;Node for SYS
LI = 1,-
NN = “SYS_I“,-
SA = 228)
#CREATE APL2:B = LIST(- ;Mirroring image appl.

NA = “IMAGE1“,-
ND = 228,-
TN = 1)

Mirroring related configurations for host 2.

LI = 1,-
NN = “SYS_I“,-
SA = 228)
#CREATE APL2:B = LIST(- ;Mirroring image appl.

NA = “IMAGE2“,-
ND = 228,-
TN = 2)

120
Number of APL-APL servers.

#SET APL1:BAA = 2
Image
Mirroring related configurations for the image.
LI = 1,-
NN = “SYS_H1“,-
SA = 232)

LI = 1,-
NN = “SYS_H2“,-
SA = 233)
#CREATE APL3:B = LIST(- ;Mirroring host appl.

NA = “H1“,-
ND = 232,- ;SYS_H1
TN = 1) ;Appl. number
#CREATE APL4:B = LIST(- ;Mirroring host appl.

NA = “H2“,-
ND = 233,- ;SYS_H2
TN = 1) ;Appl. number
Station STA9 receives messages from unit 9 of host 1 and STA109 from unit 9 of
host 2.

Number of APL-APL servers.

#SET APL1:BAA = 4
#SET APL2:BAA = 4
Station mapping definition connects station STA109 to unit number 9 in application

2.
#SET APL2:BST(9) = 109 ;Station mapping
13.3.4. Example 4. Local mirroring

Both the host and the image reside 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.
121
Mirroring configuration of the host

of the net node. The definition must be done for each mirroring station. See an
example of the definitions for unit 51 below.

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 one.
Therefore, the mirroring attributes for station 1051 are the following.

13.3.5. Example 5. Hierarchical mirroring
mir_5
Fig. 13.3.5.-1 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
configuration 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.
122
Mirroring definitions in the substation:

This is the host base system.

Create an external application (image).

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 may both receive messages from the
substation (the host) and transmit messages to the main control center (the image).
The mirroring role MR of such stations must be "BOTH".
Mirroring attributes for station 51:
#SET STA51:BMR = “BOTH“

Create two external applications, one for the image and another for the host.

NA = “SUBS“,-
ND = 232,-
TN = 1)

NA = “MAIN“,-
ND = 228,-
TN = 1)
123
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

Create an external application for the regional control center (host).

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,-
NN = “REGIONCC“,-
SA = 230)
Now the main control center configuration is ready as well.
124
14. Redundancy configurations

This chapter describes five special configurations which all serve the same purpose
to raise the operation security and availability of a running MicroSCADA system:
14.1 Hot stand-by base systems.
14.2 Redundant frontends.
14.3 Communication loops.
All three configurations above can be used combined. The engineering and
maintenance of the configurations are facilitated by tools and application software
packages.
The following two configurations describes concepts for:
14.4 Hot stand-by with OPC Client and servers.
14.5 Redundant IEC 104 slaves.
14.1. Hot stand-by base systems

The concept 'Hot stand-by base systems' means that two base system computers are
interconnected via a LAN in a redundant relationship where one or both base
systems are prepared for fast take-over 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 shadowing (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 it
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 the normal operation, the two base systems may function independently,
each running one or more applications, e.g. electrical energy distribution and district
heating. Alternatively, one base system may be reserved exclusively for stand-by
duty. Both base systems may contain several applications connected with an
application in the other base system in a shadowing relationship. In the following
description, it is for simplicity assumed that the base systems contain only one
shadowing application pair, but the same principles apply to systems with several
shadowing applications.
System architecture
Two base systems, based on the same or different hardware, are interconnected via
a LAN. The redundant base systems can share the same communication frontends,
or the communication frontends may be doubled as well.
125
Minimum 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 LAN, TCP/IP.
• One or two communication frontends connected to the LAN.
• A standard watchdog application software package in each of the base systems.
The watchdog software package contains command procedures and data objects
for monitoring the operation and reconfiguring at switch-over.
Options:
• Printers connected via the communication frontends
• Additional applications in both base systems
• Operator workstations
The most reliable Hot stand-by configuration is obtained with stations of type
S.P.I.D.E.R. RTU and SPACOM.
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 updating, including deletions, on disk under the application subdirectories
(APL_, PICT, FORM, MLIB, etc.), e.g. the process and report databases, the
picture database, text files and RTU configuration files.
• Updating of application data stored in RAM, e.g. process and report data, history
buffer and alarm buffer. Updating of cache memories, monitor states, printer
spool and execution queues are not copied.
• Last transaction number, i.e. the number of the last RP 570 or SPACOM event
message transferred from NET.
File management done outside the MicroSCADA program is not

shadowed. Therefore, always use MicroSCADA tools instead of
operating system utilities for file management (copy, delete, rename
etc.).
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 stand-
by 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.
126
Besides the shadowing data messages, the hot application sends cyclically
diagnostic commands and time synchronization commands to the stand-by
application. If it receives no 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, and starts an event channel if no
message nor any diagnostic command is 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), which may be used, e.g. for
reconfigurations and updating (e.g. updating of the last transactions on RP 570 and
SPA lines). 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 establish contact with the former hot application (which is now regarded as stand-
by application) cyclically with a specified time interval. At switch-over, the full
graphic workstations must be handled by application programs, or manually.
When the former primary computer is restarted after recovery, all files under the
redundant application directory are automatically deleted and the application files
are copied from the running application ("file dump"). Likewise, all application data
of the running application stored in RAM (e.g. process object data) is copied to the
redundant application in the recovered computer ("RAM dump"). While the RAM
data is copied, which may take some seconds depending on the application, the
running application is out of operation. The recovered computer continues as stand-
by computer. A new switch-over is obtained by a simulated error, e.g. by setting the
primary main application to cold.
14.1.1. Base system configuration procedure

1. Install the MicroSCADA Technology software as described in the Installation
manual. Do this for both base systems.
2. Edit the SYS_BASCON.HSB template and rename it. This is described in
Section 12.1.2. Do this for both base systems.
3. Configure NET units into the communication frontend. See Section 14.1.3.
4. Start the base system that should have the hot application.
5. Install the watchdog software. See Section 14.1.4.
6. Define the external watchdog application and start the main application. See
Section 14.1.5.
7. Repeat steps 5 and 6 in the other base system.
8. Edit the command procedures in the watchdog applications. See Section 14.1.6.
Do this for both base systems.
14.1.2. Editing SYS_BASCON.HSB

The MicroSCADA software delivery includes a version of SYS_BASCON.COM
template, SYS_BASCON.HSB, which contains all the necessary configuration
definitions for Hot stand-by. The easiest and most reliable method to build the base
127
system configuration for hot stand-by systems is to customise SYS_BASCON.HSB

and rename it to SYS_BASCON.COM. Except for the node numbers, the
SYS_BASCON.COM files of both base systems can be identical.
;File: Sys_bascon.hsb
;Desription: Standard Base system configuration file
; for Hot Stand-By systems
; Version 9.0
;----------------------------------------------------
@SYSTEMS = (“SYS_1”,”SYS_2”) ;SYSTEM NODE NAMES

@THIS_IS = %SYSTEMS(1) ;IP NODE NAME OF BASE SYSTEM (SYS_1/SYS_2)
@APL_NAME = “TUTOR” ;NAME OF MAIN APPLICATION

@APL_NUMS = (1,2,3,4) ;APPLICATION NUMBERS IN THE ORDER:
;(MAIN, WATCH-DOG, ADJ MAIN, ADJ WATCH-DOG)
@NO_OF_VS = 6 ;# OF VS MONITORS
@NO_OF_X = 0 ;# OF X MONITORS
@LINKS = (“*LAN”,”RAM1”,”RAM2”,”INTEGRATED”) ;USED LINKS INDICATED WITH

PREFIX “*”
@BS_NODES = (9,10) ;BASE SYSTEM NODES

@FE_NODES = (1,2) ;FRONT-END NODES
@FE_NODE_LINKS = (1,1) ;LINK NUMBER OF FE NODES
@NO_OF_STAS = 0 ;# OF STATIONS
@STA_TYP = “RTU” ;DEFAULT STATION TYPE
@STA_NOD = %FE_NODES(1) ;DEFAULT NODE FOR STA
@NO_OF_PRIS = 2 ;# OF PRINTERS
@PRI_TYP = “NORMAL” ;DEFAULT PRINTER TYPE
@PRI_NOD = %FE_NODES(1) ;DEFAULT NODE FOR PRI
#CASE %THIS_IS
#WHEN %SYSTEMS(1) #BLOCK
@MY_NOD = %BS_NODES(1)
@ADJACENT_NOD = %BS_NODES(2)
#BLOCK_END
#WHEN %SYSTEMS(2) #BLOCK
@MY_NOD = %BS_NODES(2)
@ADJACENT_NOD = %BS_NODES(1)
#BLOCK_END
#CASE_END
@l_Standard_Paths = do(read_text(“/STool/Def/Path_Def.txt”))

ND = %MY_NOD,- ;NODE NUMBER
SA = 200 + %MY_NOD,- ;STATION ADDRESS
SH = 1,- ;SHADOWING ENABLED
DS = %STA_TYP,- ;DEFAULT STATION TYPE
DN = %STA_NOD,- ;DEFAULT STATION NODE
TM = “SYS”,- ;Time Master, SYS or APL
TR = “LOCAL”,- ;Time Reference, LOCAL or UTC
FS = “NEVER”,- ;FILE SYNCH CRITERIA: NEVER,MAINT,SET,CHECKPOINT,ALWAYS
DE = 0,- ;DDE server 0=disabled, 1=enabled
OP = 1,- ;OPC server 0=disabled, 1=enabled
PC = 6000,- ;Picture Cache (kB)
RC = 1000,- ;Report Cache (kB)
- ;MS-STOOL Settings
PH = %l_Standard_Paths,-
SV = (0,- ;System Variables
128
list(t_System_Configuration_File = “sys_/SysConf.ini”,- ;System

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 = “8.4.3”)),-
- ;Operating System events
OE = 0,- ;1=Enabled, 0=Disabled
OT = (Bit_Mask(0,1,2,3,4),- ;Application events (Bit 0=ERROR, 1=WARNING,
Bit_Mask(0,1,2,3,4),- ;System events (Bit 0=ERROR, 1=WARNING,
Bit_Mask(0,1,2,3,4))) ;Security events (Bit 0=ERROR, 1=WARNING,
;LIN_BEGIN
#LOOP_WITH I = 1 .. LENGTH(%LINKS)
@NAM = SUBSTR(%LINKS(%I),2,0)
#CASE %NAM
#WHEN “LAN” #CREATE LIN1:B = LIST(LT = “LAN”)
#WHEN “RAM1” #CREATE LIN2:B = LIST(LT = “RAM”, SD = “RM00”, RE =
“BCC”)
#WHEN “RAM2” #CREATE LIN3:B = LIST(LT = “RAM”, SD = “RM01”, RE =
“BCC”)
#WHEN “INTEGRATED” #CREATE LIN4:B = LIST(LT = “INTEGRATED”,-
SC = “\SC\PROG\PC_NET\PC_NETS.EXE”)
#CASE_END
#LOOP_END
;LIN_END
;FE_NOD_BEGIN
#CREATE NOD:V ;FRONT-END NODE
#LOOP_WITH I = 1 .. LENGTH(%FE_NODES)
#SET NOD:VLI = %FE_NODE_LINKS(%I) ;LINK NUMBER
@NODE = %FE_NODES(%I)
#SET NOD:VSA = 200 + %NODE ;STATION ADDRESS
#CREATE NOD’NODE’:B = %NOD
#LOOP_END
;FE_NOD_END
;BS_NOD_BEGIN
#CREATE NOD:V ;BASE SYSTEM NODE
#SET NOD:VLI = 1 ;LINK NUMBER
#LOOP_WITH I = 1 .. LENGTH(%BS_NODES)
@NODE = %BS_NODES(%I)
#SET NOD:VSA = 200 + %NODE ;STATION ADDRESS
#SET NOD:VNN = %SYSTEMS(%I)
#CREATE NOD’NODE’:B = %NOD
#LOOP_END
;BS_NOD_END
;STA_BEGIN
ND=%STA_NOD,-
ST=%STA_TYP,-
TT=”EXTERNAL”)
#LOOP_WITH I = 1 .. %NO_OF_STAS
#SET STA:VTN=%I
#CREATE STA’I’:B=%STA
#LOOP_END
;STA_END
;PRI_BEGIN
@PRI_MAP(1..20) = 0
#LOOP_WITH I = 1 .. %NO_OF_PRIS
129
#CREATE PRI:V
#SET PRI:VND=%PRI_NOD
#SET PRI:VDT=%PRI_TYP
#SET PRI:VTT=”LOCAL”
#SET PRI:VTN=%I
#IF PRI:VND == %MY_NOD #THEN #SET PRI:VDC = “LINE”
#ELSE #SET PRI:VDC=”NET”
@PRI_MAP(%I) = %I
#CREATE PRI’I’:B=%PRI
#LOOP_END
;PRI_END
;MON_BEGIN
@FIRST_FREE_MON = 1
@MON_MAP(1..50) = 0
#LOOP_WITH I = 0 .. (%NO_OF_VS - 1)
@MON = %FIRST_FREE_MON
@FIRST_FREE_MON = %FIRST_FREE_MON + 1
@MON_MAP(%MON) = -1
#CREATE MON’MON’:B = LIST(TT = “LOCAL”, DT = “VS”)
#LOOP_END
#LOOP_WITH I = 0 .. (%NO_OF_X - 1)
@MON = %FIRST_FREE_MON
@FIRST_FREE_MON = %FIRST_FREE_MON + 1
@MON_MAP(%MON) = -1
#CREATE MON’MON’:B = LIST(TT = “LOCAL”, DT = “X”)
#LOOP_END
;MON_END
;Create Application specific global paths

@l_Global_Paths = list()
;Add LIB5xx global paths to list if LIB5xx installed

@t_LIB_Path_Def_File = “/LIB4/Base/Bbone/Use/Bgu_Glpath.txt”
#if File_Manager(“EXISTS”, Fm_Scil_File(%t_LIB_Path_Def_File)) #then #block
#error continue
@v_File_Contents = read_text(%t_LIB_Path_Def_File)
#if substr(%v_File_Contents(1),5,16) == “LIB 500 revision” and
substr(%v_File_Contents(1),22,5) >= “4.0.2” #then #block
#modify l_Global_Paths:v = do(read_text(%t_LIB_Path_Def_File))
#block_end
#error stop
#block_end
#if substr(SYS:BPR, 1, 7) == “SYS_600” #then #block ; PP
;Add SA_LIB global paths to list

@t_SALIB_Path_Def_File = “/SA_LIB/Base/Bbone/Use/Bgu_Glpath.txt”
#if File_Manager(“EXISTS”, Fm_Scil_File(%t_SALIB_Path_Def_File)) #then
#block
#error continue
@v_File_Contents = read_text(%t_SALIB_Path_Def_File)
#if substr(%v_File_Contents(1),5,14) == “SA LIB version” and
substr(%v_File_Contents(1),20,5) >= “1.0.0” #then #block
#modify l_Global_Paths:v = do(read_text(%t_sALIB_Path_Def_File))
#block_end
#error stop
#block_end
#block_end
;WD_APL_BEGIN *** LOCAL WATCHDOG ***
130
#CREATE APL:V
#SET APL:VNA = “WD” ;APPLICATION NAME
#SET APL:VTT = “LOCAL” ;TRANSLATION TYPE
#SET APL:VAS = “HOT” ;APPLICATION STATE
#SET APL:VPQ = 2 ;PARALLELL QUEUES
#SET APL:VMO = %MON_MAP ;MONITOR MAPPING
#SET APL:VPR = %PRI_MAP ;MONITOR MAPPING
;APPLICATION MAPPING
#LOOP_WITH I = 1 .. LENGTH(%APL_NUMS)
@NUM = %APL_NUMS(%I)
#SET APL:VAP(%NUM) = %NUM
#LOOP_END
@APLN = %APL_NUMS(2)
#CREATE APL’APLN’:B = %APL
;WD_APL_END
;The usage of OI & OX -attributes

@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)))
;MAIN_APL_BEGIN *** LOCAL HSB APPLICATION ***

#CREATE APL:V
#SET APL:VNA = %APL_NAME ;APPLICATION NAME
#SET APL:VTT = “LOCAL” ;TRANSLATION TYPE
#SET APL:VAS = “COLD” ;APPLICATION STATE (STARTED BY WD)
#SET APL:VPQ = 5 ;PARALLELL QUEUES
#SET APL:VPH = %l_Global_Paths;GLOBAL PATHS
#SET APL:VSV = %SV ;SYSTEM VARIABLE (RESERVED)
; #SET APL:VRC = VECTOR(“FILE_FUNCTIONS_CREATE_DIRECTORIES”),- ;Revision
compatibility
;SHADOWING MANDATORY ATTRIBUTES
#SET APL:VSN = %APL_NUMS(3) ;SHADOW APPLICATION
#SET APL:VSW = %APL_NUMS(2) ;SHADOW WATCHDOG
;SHADOWING OPTIONAL ATTRIBUTES
;WITH DEFAULT VALUES
; #SET APL:VSC = 120 ;SHADOW MAXIMUM CONNECTION TIME IN SECONDS
#SET APL:VSR = 5 ;SHADOW MAXIMUM RECEIVE WAIT TIME IN SECONDS
; #SET APL:VSI = 1000 ;SHADOW DIAGNOSTIC INTERVAL IN MILLISECONDS
#SET APL:VSY = 60 ;SHADOW TIME SYNC INTERVAL IN SECONDS
#SET APL:VHP = “DATABASE” ;History Logging Policy (“DATABASE”,
“EVENT_LOG”, “NONE”)
#SET APL:VEE = 0 ;System Events & Operating System Events
(1=Enabled, 0=Disabled)
;MONITOR MAPPING
#SET APL:VMO = %MON_MAP
;APPLICATION MAPPING
131
#LOOP_WITH I = 1 .. LENGTH(%APL_NUMS)
@NUM = %APL_NUMS(%I)
#SET APL:VAP(%NUM) = %NUM
#LOOP_END
;MAIN_APL_END
;ADJ_WD_APL_BEGIN *** ADJACENT WATHDOG ***

#CREATE APL:V
#SET APL:VNA = “ADJ_WD” ;APPLICATION NAME
#SET APL:VTT = “EXTERNAL” ;TRANSLATION TYPE
#SET APL:VND = %ADJACENT_NOD ;NODE NUMBER
#SET APL:VTN = %APL_NUMS(2) ;TRANSLATED OBJECT NR
;ADJ_WD_APL_END
;ADJ_MAIN_APL_BEGIN *** ADJACENT HSB APPLICATION ***

#CREATE APL:V
#SET APL:VNA = SUBSTR(“ADJ_” + %APL_NAME,1,10) ;APPLICATION NAME
#SET APL:VTT = “EXTERNAL” ;TRANSLATION TYPE
#SET APL:VND = %ADJACENT_NOD ;NODE NUMBER
#SET APL:VTN = %APL_NUMS(1) ;TRANSLATED OBJECT NR
;ADJ_MAIN_APL_END
;----------------------------------------------------
;Station Types
#SET STY3:BCX = “ANSI X3-28”

#SET STY4:BCX = “SPIDER RTUs”
#SET STY5:BCX = “SINDAC (ADLP80 S)”
#SET STY6:BCX = “P214”
#SET STY7:BCX = “SINDAC (ADLP180)”
#SET STY8:BCX = “PAC-5”
#SET STY9:BCX = “SATTCON/COMLI”
#SET STY17:BCX = “LON”
#SET STY20:BCX = “LCU 500”
#SET STY21:BCX = “SPACOM”
#CREATE STY22:B = LIST(NA = “SPI”, DB = “STA”, CX = “S.P.I.D.E.R/RP570”)
#CREATE STY23:B = LIST(NA = “LMK”, DB = “REX”, CX = “LonMark”)
#CREATE STY24:B = LIST(NA = “ADE”, DB = “STA”, CX = “Ademco”)
#CREATE STY25:B = LIST(NA = “PCO”, DB = “STA”, CX = “Procontic / RCOM”)
#CREATE STY26:B = LIST(NA = “WES”, DB = “STA”, CX = “Westinghouse”)
#CREATE STY27:B = LIST(NA = “ATR”, DB = “STA”, CX = “Alpha Meter”)
#CREATE STY28:B = LIST(NA = “PLC”, DB = “RTU”, CX = “PLC”)
#SET STY29:BCX = “IEC”
#SET STY30:BCX = “DNP”
;----------------------------------------------------
;Node, Link for PC-NET & Stations
@i_Status = do (read_text(“Sys_Tool/Create_C.scl”), “BASE_SYSTEM”)
To configure the hot stand-by functionality in SYS_BASCON.HSB:

1. Edit the variables in the upper part of the file. See the SYS_BASCON.HSB file
above.
SYSTEMS System node names for both base systems in the hot stand-by.
132
THIS_IS The node name of the base system in question. Note that this
number is different in the other hot stand-by base system
configurations.
APL_NAME The name of the main application. Give the main applications
the same name in both base systems.
APL_NUMS The numbers of the main and watchdog applications, and the
main and watchdog applications in the partner base system.
Other variables define the used links (marked by an asterisk) and the total number
of stations. The default stations defined in SYS_BASCON.HSB are of type
S.P.I.D.E.R. RTU ("RTU") and connected to node 1.
2. Define the base system as a SYS:B object with the Shadowing attribute SH = 1.
3. If the system contains other than default types of stations, or stations connected
to other nodes, edit the STA block. If there are several types of stations, or
stations connected to different nodes, copy the STA block and edit the copied
block.
You may also want to check the application definitions. The configurations below
are the default values that can often be used as such.
The local watchdog application, an APLn:B object with:
Shadowing State SS = "NONE"
Application State AS = "HOT"
• The external applications, APLn:B, for the main (partner) and watchdog
applications in the redundant base system. For more information, see Chapter 5.
• The main application, an APLn:B object. The following shadowing attributes are
specified:
Application State AS "COLD"
Application Mapping AP Both the watchdog application and the
external applications are mapped to
the application
Monitor Mapping MO The monitors (windows) are mapped
for the application
Shadowing Number SN The logical application number of the
shadowing application according to
the AP attribute
Shadowing Watchdog SW The logical application number of the
watchdog application according to the
AP attribute
Shadowing Flush Time SF The maximum time interval between
shadowing data transmission
Shadowing Diagnostic Interval SI The time interval between diagnostic
commands from the primary system to
the hot stand-by
Shadowing Connection Time SC Time-out for contact taking with the
stand-by application
133
Shadowing Receive Timeout SR Time-out of the hot stand-by

connection
Time Synchronization Interval SY Time synchronization interval
This base system configuration means that both main applications will be COLD
when the base systems are started, only the watchdog applications are running.
The principles for the initial configuration of Hot stand-by base systems in
SYS_BASCON.HSB are also shown in Fig. 14.1.2.-1.
Fig. 14.1.2.-1 An example of two redundant base systems

Table 14.1.2-1 Start-up configurations for two redundant base systems. The
example illustrates only the attributes and parameters that are significant for
hot stand-by.
Configuration of base system 1: Configuration of base system 2:
Base system: Base system:

SH=1 SH=1
Application 1 (Internal): Application 1 (Internal):
NA = “TUTOR” NA = “TUTOR”
AS = “COLD” AS = “COLD”
SN = 3 SN = 3
SR = 5 SR = 5
SW = 2 SW = 2
SY = 0 SY = 0
AP = (1,2,3,4) AP = (1,2,3,4)
134
Configuration of base system 1: Configuration of base system 2:

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
Application 4 (External): Application 4 (External):
NA = “ADJ_WD” NA = “ADJ_WD”
TT = “EXTERNAL” TT = “EXTERNAL”
ND = 10 ND = 9
TN = 2 TN = 2
14.1.3. NET configuration

Configure the NET units in a communication frontend as follows:
1. Define an APL object for the main application in the primary base system, see
Section 9.1.
2. Define an APL object for each of the watchdog applications in both base
systems, see Section 9.1.
3. Set the Message Application (MS) attribute to the APL number of the main
application and the System Message Enable (SE) attribute to 2.
14.1.4. Installing watchdog application
Application
The watchdog application software package handles the following procedures for all
hot stand-by applications within the base system:
• When a base system is started, it checks which main application was operating
last and sets the state of the application 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 switch-over is started and the stand-by application is set
to "HOT" and "HOT_SEND".
• If the hot system does not get acknowledgments from the stand-by system, it
regards the connection as broken, and the shadowing ceases (SS = "NONE"). The
watchdog application then checks the connection by sending commands
cyclically (with an interval of a few minutes) to the stand-by system, and starts
shadowing (SS = "HOT_SEND") when the connection has been re-established.
Installing
To install the watchdog application package:
1. Enter the Base System tool from the Tool Manager.
2. Select Base Objects.
3. Select Tools - HSB Management.
135
A window appears showing the following information:

Installed Package:The name and revision date of a previously installed package.
Status: The status of the installed package, running or not running.
Disk Package: The hot stand-by software package installed on disk
STATUS: The status of the disk package (OK, incomplete,etc.).
4. Click on Install to install the watchdog software package.
5. Wait while the watchdog software is installed. The installation creates for
example command procedures (names beginning with SHAD, data objects and
time channels). When the installation is complete, the name and revision date of
the package appears in the INSTALLED PACKAGE field.
14.1.5. Starting the shadowing

To define the external watchdog application and enable hot stand-by:
1. Click Shadowing Applications. The watchdog applications are shown in the
middle of the dialog that appears on the screen.
2. Click the field below the text External Watchdog Application, next to the
watchdog application whose pair you are about to define.
3. Type the application number of the external watchdog application.
4. Repeat steps 2-4 if you have several watchdog applications.
5. Change the HSB field from OFF to ON for a watchdog application to enable
starting the main application.
6. Wait while the main application becomes hot.
After the HSB has been enabled for both of the watchdog applications, the file dump
and shadowing starts.
Take-over should not be done before the file dump is completed.
The file dump is completed when the File dump time appears to the Shadowing
dialog, which is opened from the Applications dialog in the Base System
Configuration tool. For more information on supervising and controlling hot stand-
by systems, see Chapter 3 in the System Management manual.
14.1.6. Editing the command procedures

The watchdog application package contains command procedures, which are
described below. The following command procedures can be freely customized
meanwhile the others should not be edited. Note that while editing the command
procedures the first parts of the files should be left as they are and the modifications
are added to the end of the file.
136
SHADUSR The generation of alarms and events in the following situations:

when the hot stand-by transmission starts, when the file and
RAM dump is ready, when the connection is lost to the receiver
(in the stand-by system), when a takeover starts, or when a
change of state occurs in the partner application.
SHADMAPMON The shifting of monitors at take-over, e.g. mapping monitors for
the main application, or opening application windows using the
SCIL function OPS_CALL and the mons.exe command. See the
example in the System Management manual, Section 2.6.
When a monitor is mapped for an application, an event channel
MON_EVENT is activated. This can also be utilized for
registering the SD attribute of an X terminal, e.g. in the
Instruction (IN) attribute of a command procedure. At switch-
over, the SD attribute can be used for opening a window in the
same terminal.
SHADMAPNET Reconfiguration of the communication units at take-over. The
following NET reconfiguration should be done at take-over:
* Check of active NET if redundant frontends.
* Redefinition of the APL object in NET corresponding to the
main application, see the example in figure in Chapter 14.
* Retransmission of the last RP 570 and SPA transactions by
writing to the NETn:SLT attribute of the NET (up to 30
transactions are stored in NET).
* The reconfiguration can also be done in a command procedure
started by the event channel APL_INIT_H, which is executed
when the stand-by application is set to HOT (instead of
APL_INIT_1 and 2).
SHADGOHOT Specifies whether the main application is allowed to become
HOT when a lost connection has been discovered. The command
procedure may contain a check of the error, e.g. if the
communication disturbance is due to a communication fault on
the LAN connection to the stand-by system, no switch over
should be performed. Default: the application is set to HOT.
SHADREMHOT Specifies whether the main application is allowed to remain
HOT when also the stand-by application is HOT. Such a
situation may occur at a break on LAN. Default: the application
remains HOT.
SHADGLOBAL Defines some global shadowing variables, e.g. time constants,
the keeping of a log file on disk and log file name, etc.
Shadusr example
In this example the shadusr is used for programming functionality related to the
event list. The texts that should appear in the event list are specified in the following
situations: transmission starts, dump done, connection lost to receiver and take-over.
Below this, the texts for different state changes are specified. In the end of the
command procedure different actions are specified for the hot application appearing
when the state changes and in the other events.
137
SHADUSR - USER DEFINED COMMAND PROCEDURE FOR GENERATING ALARMS AND

; EVENTS IN USER APPLICATION
;
; INPUT PARAMETER:
; %APL (INTEGER 1 .. MAX_APPLICATION_NUMBER,
; APPLICATION NUMBER)
; %EVENT (INTEGER:
; 1 = TRANSMISSION STARTS
; 2 = DUMP DONE
; 3 = CONNECTION LOST TO RECEIVER
; 4 = TAKEOVER
; 5 = EXTERNAL APPLICATION STATE CHANGE,
; STATE STORED IN SHADEXTAS:D(%APL),
; OS == 0 => AVAILABLE,
; OS == 10 => NOT AVAILABLE,
; OV == 0 => COLD,
; OV == 1 => WARM,
; OV == 2 => HOT)
;
;-END-ABB-------------------------------------------------------------------
--
; *** EVENTLIST UPDATING ***
#ERROR CONTINUE
@NODE_NRO=SYS:BND
@SYS_NAME=SYS:BNN
@APL_NM=APL'APL':BNA
#ERROR STOP
#CASE %EVENT
#WHEN 1 @TOX ="APL 'APL_NM' Copying is started "
#WHEN 2 @TOX ="APL 'APL_NM' Copying is finished "
#WHEN 3 @TOX ="APL 'APL_NM' Connection is lost "
#WHEN 4 @TOX ="APL 'APL_NM' The application is started "
#WHEN 5 #BLOCK
#ERROR IGNORE
@S=STATUS
@ST=SHADEXTAS:DOV(%APL)
@S=STATUS
#ERROR STOP
#IF %S==0 #THEN #BLOCK
@STATE=%ST
@TOX_AS="EXT APL ADJ_'APL_NM' The state changed "
#BLOCK_END
#ELSE #BLOCK
@STATE=10
@TOX_AS="EXT APL ADJ_'APL_NM' State "
#BLOCK_END
#BLOCK_END
#CASE_END
@ACTION=%EVENT-1
#LOOP_WITH DST_APL=1..2
@APL_ST=APL'DST_APL':BAS
#IF (%APL_ST=="HOT" AND %ACTION<4) #THEN #BLOCK

#SET WD'NODE_NRO':'DST_APL'POX'APL'=%TOX
#SET WD'NODE_NRO':'DST_APL'POV'APL'=%ACTION
#BLOCK_END
#ELSE_IF (%APL_ST=="HOT" AND %ACTION==4) #THEN #BLOCK
#SET WD'NODE_NRO':'DST_APL'POX5=%TOX_AS
#SET WD'NODE_NRO':'DST_APL'POV5=%STATE
#BLOCK_END
#ELSE #BLOCK
138
;
#BLOCK_END
#LOOP_END
14.1.7. An example hot stand-by configuration

An example of base system configuration for a hot stand-by system is given here.
The system is shown in Fig. 14.1.7.-1. This example shows the content of the
command procedures that were listed above in this particular configuration. It also
shows the Sysbascon.com and monitors.dat files made for this system.
SYS 500 1 SYS 500 2

Apl1 Apl2 Apl3 Apl4
LAN
COM 510 or 530 1 COM 510 or 530 2 COM 510 or 530 3 COM 510 or 530 4
Node Number Node Number Node Number Node Number
NET1 NET2 NET3 NET4 NET5 NET6 NET7 NET8 NET9 NET10 NET11 NET12 NET13 NET14 NET15 NET16 NET17 NET18
serv_and_front.eps
Fig. 14.1.7.-1 A MicroSCADA system where there are two SYS 500 System
Servers and four COM 510 or 530 Communication frontends
Shadusr
In this example configuration there is no modifications made to the Shadusr.
Therefore, hot stand-by functionality related events and alarms are not generated
and shown to the operator.
LN = "SHADUSR",
CM = "USER DEFINED PROCEDURE FOR ALARM AND EVENT HANDLING", IU = 1,
ZT = 98-11-26 11:13:37, EP = 255, SE = 0, TC = "", PE = 0, PQ = 0,
HN = 0, MO = 1, IN =
; SHADUSR - USER DEFINED COMMAND PROCEDURE FOR GENERATING ALARMS AND
; EVENTS IN USER APPLICATION
;
; INPUT PARAMETER:
; %EVENT (INTEGER:
; 1 = TRANSMISSION STARTS
; 2 = DUMP DONE
; 3 = CONNECTION LOST TO RECEIVER
; 4 = TAKEOVER
; 5 = EXTERNAL APPLICATION STATE CHANGE,
; STATE STORED IN SHADEXTAS:D(%APL),
; OS == 0 => AVAILABLE,
; OS == 10 => NOT AVAILABLE,
; OV == 0 => COLD,
; OV == 1 => WARM,
139
; OV == 2 => HOT)
;
;-END-ABB-----------------------------------------------------------
Shadmapmon
In this example configuration the monitors that are opened at take-over are specified.
The first part of the command procedure ending with the text
;-END-ABB------------------------------------------
is ready made. The text after this is the project specific part made by the project
engineer.
If the base system with the node number 21 becomes hot at the take-over, 3
predefined monitors of number 4 and 3 predefined monitors of number 5 will be
opened with the ops call to the computer named JSE_SYS1. When the base system
with the node number 22 becomes hot at the take-over, 3 predefined monitors of
number 4 and 3 predefined monitors of number 5 are opened to the computer named
JSE_SYS2. For more information about opening a predefined monitor and
monitors.dat file, see Chapter 2 in System Management.
LN = "SHADMAPMON",
CM = "USER DEFINED PROCEDURE MAPPING MONITORS AT TAKEOVER", IU = 0,
ZT = 99-04-14 13:05:25, EP = 255, SE = 0, TC = "", PE = 0, PQ = 0,
HN = 0, MO = 1, IN =
; SHADMAPMON - USER DEFINED COMMAND PROCEDURE FOR MAPPING MONITORS
; AT TAKEOVER
;
; INPUT PARAMETER:
; %APL (INTEGER 1 .. MAX_APPLICATION_NUMBER)
;
;-END-ABB------------------------------------------------------------
#Error Continue
@HOT=SYS:BND
#CASE %HOT
#WHEN 21 #LOOP_WITH I=1..3
@I=%I+1
@OPS=OPS_CALL("MONS -N -D JSE_SYS1 4",1)
#LOOP_END
#WHEN 22 #LOOP_WITH I=1..3
@I=%I+1
#LOOP_END
#CASE_END
Shadmapnet
In this example configuration the monitors that are opened at take-over are specified.
The first part of the command procedure ending with the text
;-END-ABB------------------------------------------
140
is ready made. The text after this is the project specific part made by the project
engineer.
First the time is specified in which data should have been received from the NET.
Then the numbers of the NETs, applications and base systems in the application
named JSE are specified. Then there are programs that translate:
LN = "SHADMAPNET",
CM = "USER DEFINED PROCEDURE FOR CONFIGURING NET'S AT TAKEOVER",
IU = 1, ZT = 99-03-15 01:11:02, EP = 255, SE = 0, TC = "", PE = 0,
PQ = 0, HN = 0, MO = 1, IN =
; SHADMAPNET - USER DEFINED COMMAND PROCEDURE FOR RECONFIGURING
; MICROFRONTENDS AT TAKEOVER
;
; INPUT PARAMETER:
; %APL (INTEGER 1 .. MAX_APPLICATION_NUMBER)
;
;-END-ABB----------------------------------------------------------------
---
#ERROR CONTINUE
@DT = 120 ; IF SOMETHING RECEIVED FROM NET WITHIN %DT SECONDS

; CONSIDER IT AS REACHABLE
@My_Nod = SYS:BND
#CASE APL1:BNA
#WHEN "JSE" #BLOCK
@NETS=(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18)
@APLS=( 5, 6, 7, 8)
@SYSS=(23,24,25,26)
#BLOCK_END
#OTHERWISE #BLOCK
@S=CONSOLE_OUTPUT("SHADMAPNET UNKNOWN APPLICATION")
#BLOCK_END
#CASE_END
#LOOP_WITH I = 1 .. LENGTH(%NETS) ; Switch the NET units

@T=Times
@NET=%NETS(%I)
#If Nodes:P'NET' == 1 #Then #Block
@a = Console_output("'T' Shadmapnet NET='net' My_Nod = 'my_nod'")
#set Net'NET':SSY1=(%My_Nod,1)
#Block_end
#LOOP_END
#LOOP_WITH I = 1 .. LENGTH(%APLS) ; Switch the application in the COM Nodes

@COMAPL=%APLS(%I)
@COMNOD=%SYSS(%I)
@A = Timeout(500)
#Error Continue
#Set APL1:'COMAPL'BTT="NONE"
#Set APL1:'COMAPL'BND=%My_Nod
#Set APL1:'COMAPL'BTT="EXTERNAL"
@T=Times
@a = Console_output("'T' APL1 from Node 'COMAPL' to Node 'My_Nod' ")
#LOOP_END
141
Shadgohot
LN = "SHADGOHOT",
CM = "USER DEFINED CHECKS FOR STARTING STANDBY APPLICATION", IU = 1,
ZT = 99-03-03 18:28:32, EP = 255, SE = 0, TC = "", PE = 0, PQ = 0,
HN = 0, MO = 1, IN =
; SHADGOHOT - USER DEFINED COMMAND PROCEDURE FOR CHECKING WETHER
; APPLICATION IS ALLOWED TO HOT OR NOT WHEN THE SHADOWING
; HAS DISCOVERED A CONNECTION LOST
;
; INPUT PARAMETER:
; OUTPUT PARAMETER:
; %GO_HOT (BOOLEAN, TRUE OR FALSE)
;
;-END-ABB--------------------------------------------------------------
@A = Console_Output("SHADGOHOT:C Begin")
@a = Timeout(500)
@Counter=0
@New_Node = (9,10,11,12,13,14,15,16,1,2,3,4,5,6,7,8,18,17)
#Loop_With J = 1 .. Length(%New_Node)
#error Continue
@nods=Nod'J':ssa
@Know = status
#If %Know == 0 #Then @Counter = %Counter + 1
#Error Continue
#Loop_End
#If %Counter >= 1 #Then @Go_hot = TRUE

#If %Counter == 0 #Then @Go_hot = FALSE
@a = Timeout(0)
@A = Console_Output("SHADGOHOT:C Go_Hot = 'Go_Hot'")
Shadremhot
LN = "SHADREMHOT", CM = "CHECK IF ALLOWED TO REMAIN HOT", IU = 1,
ZT = 99-03-10 13:48:51, EP = 255, SE = 0, TC = "", PE = 0, PQ = 0,
HN = 0, MO = 1, IN =
; SHADREMHOT - USER DEFINED COMMAND PROCEDURE FOR CHECKING WETHER
; APPLICATION IS ALLOWED TO REMAIN HOT AFTER DISCOVERING
; THAT ALSO THE SHADOWING PARTNER IS HOT
;
; INPUT PARAMETER:
; OUTPUT PARAMETER:
; %REMAIN_HOT (BOOLEAN, TRUE OR FALSE)
;
;-END-ABB----------------------------------------------------------------
@A = Console_Output("SHADREMHOT:C Begin")
@a = Timeout(500)
@NET_CNT = 0
@New_Node = (9,10,11,12,13,14,15,16,1,2,3,4,5,6,7,8,18,17)
@BS_NODE=SYS:BND
@APL_NODE=%BS_NODE*10000+%APL
#Loop_With J = 1 .. Length(%New_Node)
#Error Continue
@NET_NRO = %New_Node(%J)
@ST = NET'NET_NRO':SSA
@STS = STATUS
142
#If %STS==0 #Then #Block

#If NET'NET_NRO':SSY'APL'==%APL_NODE #Then #Block
@NET_CNT=%NET_CNT+1
#Block_End
#Block_End
#Loop_End
#If %NET_CNT >= 1 #Then @REMAIN_HOT=TRUE

#If %NET_CNT == 0 #Then @REMAIN_HOT=FALSE
@a = Timeout(0)
@A = Console_Output("SHADREMHOT:C Rem_Hot = 'Remain_Hot'")
Shadglobal
LN = "SHADGLOBAL", CM = "GLOBAL DEFINITIONS", IU = 1,

ZT = 98-11-26 11:16:49, EP = 255, SE = 0, TC = "", PE = 0, PQ = 0,
HN = 0, MO = 1, IN =
; SHADOW GLOBAL DEFINITIONS
;
;
@MAX_APL = MAX_APPLICATION_NUMBER ;MAXIMUM # OF APPLICATIONS

@MAX_NET = MAX_NODE_NUMBER ;MAXIMUM # OF NETS
@CHK_NET_START = FALSE ;CHECKS FOR NET CONNECTIONS

;AT FORCED APPLICATION START
@CHK_EXT_SP = FALSE ;CHECKS FOR SHADOWING PHASE FOR

;EXTERNAL APPLICATIONS
@LAPL_START = 60 ;SECONDS TO WAIT FOR LOCAL

;APPLICATION TO START
@EAPL_START = 60 ;SECONDS TO WAIT FOR EXTERNAL

;APPLICATION START RESPONSE
@SHD_RESTART = 200 ;SECONDS BEFORE TRYING TO RESTART

;TRANSMISSION
@NET_CONN = 300 ;SECONDS SINCE LAST MESSAGE FROM NET

;BEFORE CONNECTION CONSIDERED BROKEN
@RCV_MATRIX = ("SHADRCV_M","SHADBCK_M") ;TRANSITION MATRIXES FOR REVEIVER

@XMT_MATRIX = ("SHADXMT_M","") ;TRANSITION MATRIXES FOR TRANSMITTER
;(<EXT SHADOWING>,<INT SHADOWING>)
@BCK_PROC = "SHADBACKUP" ;NAME OF PROCEDURE TO PERFORM BACKUP
@HSB_LOG = TRUE ;ENABLE/DISABLE LOGGING OF HSB EVENTS ON DISK

;IN THE FILE "SYS_SHADOW.LOG"
@LOG_FILE = "SYS_SHADOW.LOG" ;NAME OF LOGFILE
; EVENTS FOR SHADUSR

@TR_START = 1 ;TRANSMISSION STARTS
@DUMP_DONE = 2 ;DUMP DONE
@CONN_LOST = 3 ;CONNECTION LOST TO RECEIVER
@TOVR = 4 ;TAKEOVER
@EXTAS = 5 ;EXTERNAL APPLICATION STATE CHANGE
;USER REDEFINITIONS AFTER THE FOLLOWING LINE

;-END-ABB-------------------------------------------------------------
143
14.2. Redundant frontends

The concept 'Redundant Frontends' means that two communication frontends are
dedicated for the same tasks. One communication frontend is operating (the hot
frontend) and the other one is a reserve communication frontend (secondary or
stand-by frontend). The stand-by frontend is not operating but running and ready to
take over at malfunction in the hot one. When a take-over occurs, the former stand-
by frontend becomes the hot one and takes over the communication on all lines.
Normally, the communication frontends are equal and the stand-by frontend can be
shifted to hot frontend and vice versa.
During operation some RP 570 information is transferred between the two frontends
on event basis. Redundant frontends including transfer of event data between the
communication frontends are only supported with S.P.I.D.E.R. RTUs and the RP
570 protocol. If other protocols are used, a switch-over between communication
frontends is possible, but such RTU information, which cannot be obtained with a
general interrogation may be lost.
In most cases Redundant Frontends are combined with Redundant MicroSCADA
applications, see Section 14.1, although these are two independent functions. They
can also be used with communication loops as described in Section 12.3. The data
transfer between the communication frontends may slow down the RTU polling
compared with single frontends.
A standard application software package is available for handling redundant
frontends. Both the frontend supervision and the application software package are
based on switching one NET pair individually at a time. This means that
communication frontends containing several redundant NET units require additions
to the standard package.
System architecture
A redundant frontend pair consists of:
• Two communication frontends with one communication board in each.
Additional boards require extensions to the standard redundant frontend
application software.
• Line switches with 1...7 external RP 570 lines for RTU communication. There is
one line switch per Process Station line.
• A standard redundant frontend application software package.
Each of the communication frontends is permanently connected to one or more (up
to four) base systems via a LAN. One base system can be connected via a COM port
and a serial RS-232-C line.
The two frontends must be interconnected for transmission of event data, either via
a COM port or a NET line. If a COM port is occupied for a base system connection,
the communication frontends are connected via a NET line.
Both communication frontends are permanently physically connected to all line
switches. The switches are controlled by a DTR signal issued by the stand-by
frontend. As long as the DTR signal from the stand-by frontend is passive, the RTUs
are connected to the hot frontend. When DTR is activated by the stand-by frontend,
144
the line switches turn towards this one, which gets the Process Station connections.
Provided that the line switches are sensitive to the rising DTR edge, the former hot
frontend can take the lines back after recovery. The operation of the RTUs is not
effected by the NET redundancy procedures.
The frontend switching can be initiated by the operator from the NET configuration
tool picture, e.g. for testing purposes.
During normal operation, the hot NET sends the following data cyclically to the
stand-by NET:
• RTU event information and RP 570 line status
• Communication loop configuration data
Table 14.2.-1 Information transferred from the running NET to the standby
NET
WHEN WHAT
At event reception Event sequence number

When RTU device status changes RTU device status
At line status change Line status of a line , communication loop data of
line if communication loop configured on line
At communication loop configuration Communication loop data of a line
At communication loop build-up Communication loop data of a line substatus
change
When there is no information to send, a diagnostic message is sent cyclically. The

stand-by NET supervises the time between the messages from the hot NET. If a
time-out occurs, it sends a system message to the MicroSCADA application (the
message application, the MS attribute, see Section 8.1.) telling that the hot NET has
failed. The application decides whether to execute a take-over, and performs it when
needed.
If a NET loses its connection to the message application, it will report this as a
failure to the other NET, which tries to inform the application about the failure.
NET configuration
The NET programs of the both redundant communication units have the same
preconfiguration, except for the node number, ACP station address and system
message handling attributes. Both NETs are basically defined as described in
Section 8.1. The NETs must know each other as nodes residing on the redundant
connection line, i.e. either a NET line or a serial line via a COM port. Regarding the
connected stations and applications, both NETs must have exactly the same
configuration.
To build two redundant frontends, configure each of the NETs as follows in the
preconfiguration of the NET programs:
1. Define the fundamental configuration of the NET as described in Section 8.1.
Use the default MI values for system message addresses. If there are ANSI
stations, the SX attribute must be the same in both NETs. Define the NET
system message enabled SE attribute to value 2.
2. Check that line 13 is defined for the common RAM interface.
145
3. If the redundancy information will be sent via a NET line, define the line as an
ACP line with the following attributes:
PO Protocol: 00001
IU In Use: 00001
MI Message Ident: 00000
LK Link Type: 00000
BR Baud Rate: 09600
SB Stop Bits: 00001
PY Parity: 00002
OS Output Synchronise: 00000
RE Redundancy: 00002
TI Time-out Length: 00001
NA NAK Limit: 00001
EN ENQ Limit: 00001
DE CTS Delay Length: 00000
PD Poll Delay: 00000
P Polling Period: 00000
CN Connection: [Ign]
4. Define the redundant partner NET as an external node, either on line 13 (if the
COM port is used), or on the NET line reserved for the redundant
communication.
5. Define the same STA objects and APL objects in both NETs, see Chapters 11 -
13.
All the STA definitions in both NETs must also be defined as STA objects in the
base systems.
Possible on-line configuration changes must be done in both communication
frontends. The only on-line configuration changes that are automatically transferred
between the communication frontends are communication loop data structures.
To restore the preconfiguration of the running NETs, restart them by setting the RS
attribute of the communication frontend to 3.
146
Frontend configuration
Include the following configuration parameters in the MFLCONF.DAT file of each
of the redundant frontends:
1. Set CMOD =2 for the redundant NET.
2. Set CPNOD = the node number of the pair NET in the partner frontend (default
= subsequent numbers, 1 - 2, 3 - 4, etc.).
3. If the redundant communication will go via the COM1 port, define the peer
NET by the DST parameter.
4. Define the base system communication parameters.
LAN
Base system 1 Base system 2

Apl1 Apl2 Apl3 Apl4
Frontend Frontend
Node Number: Node Number:
Net 1 Net 4
Line 8 Line 8
Refeconf.eps
Fig. 14.2.-1 An example of two redundant frontends, when the redundancy

information is transferred via a NET line
147
Table 14.2.-2 An example configuration of two redundant frontends when the redundancy information is
transferred via a NET line. If the base systems are doubled, both base systems contain the same
configuration regarding the frontends and the RTUs.
Configuration of NET1 Configuration of NET4
This Node: This Node:

RAM Size (kB): 512 RAM Size (kB): 512
Device Number: 1 Device Number: 4
MI Message Ident.: 6001 MI Message Ident.: 6004
MS Message Application: 1 MS Message Application: 3
SA Station Addr. (dec.): 201 SA Station Addr. (dec.): 204
SE System Message 1 SE System Message 1
Enabled: Enabled:
Line 13 (=RAM Interface) Line 13 (=RAM Interface)
PO Protocol: 3 PO Protocol: 3
IU In Use: 1 IU In Use: 1
MS Message Applications: 5 MS Message Applications: 5
RE Redundancy: 2 RE Redundancy: 2
TI Time-out Length: 2 TI Time-out Length: 2
NA NAK Limit: 3 NA NAK Limit: 3
NE ENQ Limit: 3 NE ENQ Limit: 3
PS Buffer Pool Size: 50 PS Buffer Pool Size: 50
External Node 4 (NET 4) External Node 1 (=NET 1)
Device Type: NOD Device Type: NOD
Device Number: 4 Device Number: 1
LI Line Number: 3 LI Line Number: 3
SA Station Addr. (dec): 204 SA Station Addr. (dec): 201
Line 8 (=ACP line) Line 8 (=ACP line)
PO Protocol: 1 PO Protocol: 1
MS Message Application: 1 MS Message Application: 1
See Section 8.4. See Section 8.4.
Frontend Configuration Frontend Configuration
DST1 = 209 DST1 = 209
DST2 = 210 DST2 = 210
CMOD1 = 2 CMOD1 = 2
CPNOD1 = 4 CPNOD1 = 1
Standard application software package

The standard application software for redundant frontends controls the
communication between the redundant frontends. It receives system messages from
the frontends and control the frontend modes using the Running Mode (RM) and
148
Shadowing (SH) attributes of NET. When a communication frontend is started, the

initial redundancy mode is defined by the CMOD parameter in the frontend
configuration file, see above.
If the stand-by NET detects a severe failure in the hot frontend, it sends a system
message containing a switch-over request to a MicroSCADA application (e.g. the
watch-dog application if hot stand-by). On the basis of the system messages, and
possibly further conditions, the application decides whether to perform a switch-
over or not. The switch-over is executed by the command procedures included in the
standard redundant frontend software package. These procedures execute, e.g. the
following steps:
• Changes the stand-by NET to HOT, by setting its RM attribute to 1 and the SH
attribute to 1.
• Takes the RTU lines in use by setting the IU attribute to 1. When a line is taken
into use, DTR is automatically activated and the NET takes hold of the lines.
• Redefines the stations in the base system with the NET node number, e.g. #SET
STAn:BND = 4.
• Commands the new hot NET to send an SCI (status request) to all RTUs using the
SC attribute.
• Takes the RTUs into use by setting the IU attribute = 1.
Installing standard software

The MicroSCADA tool software contains tool pictures (SYSORF_ADM) for
installing and taking the standard application software package for redundant
frontends into use. To take the software package into use:
1. Enter the application which will contain the application software, and enter the
tool menu NET SPECIAL CONFIGURATION and select REDUNDANT
FRONT-END INSTALLATION.
2. Press the INSTALL RF OBJECTS key, which will install command procedures,
datalogs, time channels and event objects into your system. The names of the
created objects start with letters RF_.
3. Press the CREATE/VIEW NET PAIRS key to select the redundant NET pairs.
Type in the group numbers and the node numbers of the NETs. For each
redundant frontend you must use a unique group number. Press the INSTALL
key to save your settings.
4. Press the CHOOSE/VIEW RF LINES key. Type in the node number of the
NETs and mark the numbers of the NET lines, which are operated by the RF
procedures.
5. Press the CREATE LIST OF OBJECTS key. This will search your base system
configuration for STA and PRI objects and then it will create two vector
variables into the RF_U_BOBJ:C command procedure. RF_STAOBJ variable
contains the numbers of base system station objects that are controlled by the
RF procedures. RF_PRIOBJ contains the numbers of base system printer
objects that are controlled by the RF procedures. The command procedure can
be modified manually to add or to remove objects from the list, or it can be
created again with the CREATE LIST OF OBJECTS KEY.
149
6. If you have a combination of redundant frontend and hot-standby base systems,

you should press the INSTALL OBJECTS FOR HSB APL key. This will create
a RF_U_WD:C command procedure into your WD application.
Application specific procedures

Redundant frontend command procedures that need application specific
modifications are named with letters RF_U_*.
RF_U_BOBJ:C
This command procedure is used to store an array of base system STA and
PRI objects which are controlled by the RF procedures. This is done with
two vector variables:
RF_STAOBJ contains the numbers of base system station objects that are
controlled by the RF procedures.
RF_PRIOBJ contains the numbers of base system printer objects that are
controlled by the RF procedures
This procedure can be done manually or from the tool with the CREATE
LIST OF OBJECTS key.
RF_U_CHECK:C
This command procedure is used to perform a cyclical check of redundant
NETs. The procedure is executed by a RF_U_CHECK time channel. The fol-
lowing checks have been included as a default.
• RF_U_WD:C in watchdog application is executed to remap the main
application. This is necessary only when the hot-standby base system is used
together with a redundant frontend.
• Checks that the system messages enabling attribute (SE) in NET is 1, if not it is
changed to 1.
• Checks that the NET pairs are not in the same running state (both standby or
hot). If they are in the same state, the switch over procedure will be started.
RF_U_LIN:C
Sets a line of the new hot net in use on switch-over. This command proce-
dure is executed by the switch-over procedures for all the NET lines, which
have been chosen in the tool picture. This procedure can be used in most
applications without any modifications.
RF_U_NETMS:C
NET system message handling for application specific purposes. This com-
mand procedure receives the three different types of NET system messages
(General, APL diagnostic, NET diagnostic). By default, this procedure is
used for the following functions.
• When the main application connection of the hot NET is restored, this
procedure is used to map the base system objects to that NET. This is done by
executing the RF_BOBJ_SB:C command procedure.
• When the main application connection of any NET is restored, this procedure
is used to start the on-line configuration of the NET.This is done by executing
the RF_U_ONLC:C command procedure.
150
RF_U_ONLC:C
This procedure will be used, if on-line configuration of the NET is needed.
RF_U_STA:C
Sets the stations in use and makes station specific actions on switch-over.
14.3. Communication loops

A communication loop means that several RTUs are connected on the same line (in
a loop) to two NET lines in the same or separate communication units, situated in
the same or separate frontends, see Fig. 14.3.-1. The purpose is to secure the contact
between the base system and the RTUs even if the loop line is physically broken in
one location. Communication loop is available exclusively for S.P.I.D.E.R. RTUs,
whereby NET acts as an RP 570 master station.
The communication between the base system and the RTUs can go in any loop
direction, but only in one direction at a time. The communication can be redirected
with SCIL. The RTUs also change the communication direction automatically, if
they are not polled within a certain point of time. A loop reconfiguration normally
lasts for several minutes and not all RTUs are accessible during that time. The
performance of a communication loop line is somewhat slower than normal modem
lines, because telegrams may have to pass through several modems in the loop.
The communication loop implementation in MicroSCADA involves functions both
in the NET and in the MicroSCADA application.
System architecture
Hardware requirements:
• A Loop control unit DSTC3002 or equivalent and two modems at each RTU
Software requirements:
• DCP-NET or PC-NET software, revision 8.2 or 8.4.
• MicroSCADA base system base product software revision 8.2 or 8.4.
• RTU200 or RTU210 software rel. 2. including loop support
• Communication loop application software package
Each RTU is equipped with a loop reversal unit and two modems. The ends of a
communication loop can either be connected to two lines of the same NET unit or
to two lines of different NETs (as in the example configuration on the following
page). The maximum number of RTUs per loop is 16. Branched communication
loop lines are not supported.
A maximum of 10 loops is allowed per application.
151
LAN
Base System 1
Front end Front end
Loop reversal unit
RTUs Communication_loop.eps
Fig. 14.3.-1 An example of a communication loop connected to two separate

communication frontends
The loop has a logical breakpoint, normally near the midpoint of the loop. All RTUs
on one side of the breakpoint are polled from that direction and the RTUs on the
other side are polled from the other direction. The breakpoint can be moved to any
loop segment, thus, all the RTUs can be even polled from the same direction.
Each RTU controls its own loop reversal unit and can change the listening direction
by opening or closing its loop reversal unit. The breakpoint is formed where two
adjacent RTUs are linked to different directions. A NET can command an RTU to
change the state of its loop reversal unit with an RP 570 command. If the RTU is not
polled from the current direction with other telegrams than SCI in the loop reversal
time, it will automatically turn its loop reversal unit and listen in the other direction.
Consequently, under all circumstances, all RTUs must be polled within this time,
otherwise some RTUs may turn to the wrong direction.
The loop reversal time-out is configured in the RTU, and can be set with an FTAB
command. The loop reconfiguration time depends on the number of RTUs in the
loop and the loop reversal unit turn time-out in the RTUs. An automatic
reconfiguration of a loop with 16 RTUs may take a few minutes.
If an RTU polled from one direction is suspended, a system message is sent to the
message application of the RTU in question. The application waits for a while. If one
or more RTUs are still suspended, a loop reconfiguration starts. The breakpoint can
be moved, e.g. so that all the suspended RTUs and all the RTUs situated between
them on the loop are polled from the other direction. During the reconfiguration, the
loop reversal units of the RTUs are turned according to the physical order of the
RTUs on the loop, and the loop is thus extended step by step.
152
When a NET starts to poll an RTU which has been shifted from the other direction,
it always starts with a status check (SCI). This means that the latest indication and
measured values are transmitted by the RTU. Events, pulse counter messages and
other queued data (from the four last telegrams if found) are automatically
retransmitted by the RTU. Therefore, no RTU information gets lost.
The communication loop configuration is built on-line. The standard loop
application software loads the communication loop configuration each time the
NETs have been restarted. If the NETs controlling the loop have redundant NETs,
the configuration commands will be forwarded to the stand-by NET. Information is
forwarded several times during a loop reconfiguration procedure.
NET configuration
Communication loop sets no special requirements on the preconfiguration of the
NETs. No direct communication between the separate NETs which control the two
ends of a loop is required. The NETs are defined to one another as normal nodes as
described in Chapter 8.
1. Define the loop line in both NETs. The line is configured as an ordinary RP 570
line, see Section 11.1.
2. Define all RTUs in both NETs. The RTUs in the loop are not in use (IU = 0).
Loop application software

The MicroSCADA tool software package includes two tool pictures for
communication loop handling, one for the installation and administration of the loop
software (SYSOLOOCON) and one for supervision of the loop operation
(SYSOLOOSUP).
To install or edit the loop application software:
1. Enter the application which will contain the software.
2. Enter the tool SYSOLOOCON.
3. Select a loop in the list (1 ... 10) by clicking on it, an empty number to add a new
loop, or a loop name to a view or edit an existing one.
4. Define the loop in the loop window which appears by a freely chosen loop
name. Define also the node numbers of the NET, the loop line numbers and the
following loop communication parameters:
CONFIG. TIME = Time limit for the NETs to get connection to all RTUs after loop
reconfiguration
BREAK TIME = Time from first RTU suspensions to decision if an automatic
reconfiguration will be done or not
SCAN TIME = Maximum scan time, the MT attribute. The time allowed for
obtaining connection with the next RTU on the loop after re-
configuration.
5. Select SHOW RTUs to view, add and edit the RTUs of the loop.
6. Add a new RTU to the loop by selecting ADD RTU, by clicking on the location
of the RTU on the loop line and defining the RTU in the window. You can also
edit an existing RTU by clicking on it on the loop and redefining it in the RTU
window. RTUs can be removed from the loop by clicking on REMOVE RTU
and then the RTU symbol in the loop figure. They cannot be moved. The RTUs
153
are defined by a freely chosen name, the STA object number, listening direction,
and loop switch state.
7. When the loop is ready, build the application command procedures by clicking
on INSTALL CMD PROCEDURES.
The function keys CHANGE DIRECTION, OPEN/CLOSE, and SET BREAK do
not affect the configuration of the loop.
14.4. Hot stand-by with OPC client and servers

This chapter describes the principles of the HSB concept in systems including OPC
clients and servers connected to IEC 61850 process devices.
HSB_61850
Fig. 14.4.-1 Typical HSB system with IEC 61850 process communication
Both computers, A and B, consist of their own MicroSCADA base system, OPC
Data Access Client and IEC 61850 OPC Server.
When a fault occurs in the primary base system (computer A) including the HOT
application, the shadowing application in the stand-by base system (computer B) is
started and it takes over all the operational functions.
Typically there is need to minimize the switch-over time in the Hot-Stand-By
systems.
Hot stand-by
The watchdog application in the stand-by base system monitors the diagnostic
commands and messages from the hot application. If no message or diagnostic
command is received within a specified time, the watchdog application examines the
situation and performs a switch-over if needed.
154
When the stand-by application is set to HOT, a predefined event channel

APL_INIT_H is started to be used for re-configuration purposes. See more
information in the chapter for hot stand-by base systems.
Configuration examples - IEC 61850 OPC client

In the SYS_BASCON.COM you need a node definition for a IEC 61850 OPC Client
; IEC61850 OPC_Client_Nod_begin
#CREATE NOD:V ;Client node
#SET NOD:VLI = 1 ;Client Link number
@NODE = 8 ;Node number
#SET NOD:VSA = 208 ;Node address
#SET NOD:VNN = "HSB1" ;Name of the base system
#SET NOD:VDI = 10 ;Diagnostic interval
#SET NOD:VDT = 30 ;Diagnostic timeout
#CREATE NOD'NODE':B = %NOD ;Creating node
; IEC61850 OPC_CLIENT_Nod_end
For the creation of stations include this in the SYS_BASCON.COM file

TT = "EXTERNAL",-
ST = "SPA",-
TR = "UTC",-
ND = 8,-
TN = 60)
#CREATE STA60:B = %STA
Configuration examples - OPC Data Access Client
Fig. 14.4.-2 Setting of the client communication parameters
In this configuration set the stations in use. Use ‘Enable Circular Buffering’ in the
OPC Configuration Tool (see figure in chapter ‘Event Buffering Policies’).
155
CPI_Node_properties
Fig. 14.4.-3 Here is an example of the CPI node parameters settings.
HSB_install_packages
Fig. 14.4.-4 Hot stand-by install packages
156
HSB_install_applications
Fig. 14.4.-5 Hot stand-by install applications

Starting of the IEC 61850 OPC Client can be done in the WD application or in a
separate application to start both PC-NETs and the IEC 61850 OPC Clients.
APL_INIT_1:C
;This is executed when application gets hot

#exec_after 10 start_opc_da_client_instance:c ;Start Client after a delay
START_OPC_DA_CLIENT_INSTANCE:C
#error ignore
@abb = ops_call("C:\sc\prog\OPC_Client\DA_Client\daopccl.exe -id ""iec61850""
-start ""C:\sc\sys\active\sys_\iec61850.ini"" -trace normal",0) ;
alternative -trace high
Stopping of the Client:

Add line starting with ‘#exec’ below to the Shutdown.cin in the sc\prog\exec
directory:
;Insert site specific code here
#exec STOP_OPC_DA_CLIENT_INSTANCE:11C ;Stop OPC DA Client instances
; Shut down applications

; Search watch dog applications (normally there is one wd in a system)
Create a STOP_OPC_DA_CLIENT_INSTANCE:C
#error ignore
@abb= ops_call("C:\sc\prog\OPC_Client\DA_Client\daopccl.exe -id ""iec61850""
-stop",0)
157
IEC 61850 OPC Server

In the Hot-Stand-By system, the IEC 61850 OPC Servers should be active both in
primary (including hot application) and stand-by (including shadowing application)
computer. This enables that data coming from IEC 61850 process devices is stored
into buffers of the both IEC 61850 OPC Servers all the time.
OPC Data Access Client
OPC Data Access Client should be located in the same computer, where base system
is running. When application changes to HOT state, the OPC Data Access Client
should become configured using the application initialization procedures
(APL_INIT_*) as defined in OPC Data Access Client manual.
OPC Data Access Client is located in the same computer, where the Base System
itself, so there is a need to configure only the Primary MicroSCADA information in
the CPI Node Properties of OPC Data Access Client.
OPC Data Access Client - Event Buffering Policies
In a situations, where OPC Data Access Client looses a connection to a
MicroSCADA base system, there is a need to configure the event buffering policy.
The policy, how the OPC Data Access Client buffers events, can be specified to be
one of the following:
Disable Buffering
When the policy is Disable Buffering, the OPC Data Access Client does not buffer
the events.
Enable Normal Buffering

When the policy is Enable Normal Buffering, the OPC Data Access Client buffers
the events in a way that the latest update is always stored into the buffer. This occurs
independently of the process object type. This is also the default setting.
Enable Cicular Buffering

When the policy is Enable Circular Buffering, the OPC Data Access Client buffers
the events in a way that changes of switching device indications always are stored
into the buffer as own entries, i.e. all the state transitions are stored. Regarding
updates of measurements, the latest update is always stored into the buffer. In the
case of Hot-Stand-By systems this policy results in a situation, where the same
events may appear more than twice after the communication break. However, all the
changes of the switching device indications are stored during the communication
break, as long as the size of the buffer has not been exceeded.
158
PC_Client_parameters
Fig. 14.4.-6 OPC Configuration Tool - Enable Circular Buffering

IEC 61850 Process Devices
IEC 61850 process devices should be configured to sent information simultaneously
to both servers (double master system).
14.5. Redundant IEC 104 slaves
HSB_104
Fig. 14.5.-1 Example of system with redundant IEC 104 slaves
159
For each NCC connection there will be a separate IP interface. Three interfaces are
needed in the system example above in both COM500 computers for the NCC
connections. Each interface is assigned with an unique IP address. A switch is used
to connect different Ethernet cards to the network. It is also possible to use multiple
IP-addresses with one card as there is no restrictions in MicroSCADA to use this
configuration.
Three different IEC 104 communication slave lines should be created, one line per
IP-interface. Each line uses its own IP-address, defined with the LD-attribute of the
line.
In the Stand-By COM 500 Computer, the communication lines should be IU = 0
Limitations
• no keep-alive connection to stand-by COM500
• the switch is initiated by the Hot-Standby application of the COM500 and not by
the NCCs
• events may be lost or doubled when the COM500 switch occurs
Assumptions
• IEC104 master in NCC tries to establish the connection to another IP-address
(another COM500) when the communication has been broken for a
preconfigured time.
• Fixed IP-addresses are used, the network interfaces are non-removable.
160
15. Miscellaneous
15.1 Handling of the system messages generated in the communication
units.
15.2 Configuration of auto-dialling.
15.3 Time synchronization.
15.4 Storing the event history.
15.1. System message handling

System messages are generated by the communication units at the appearance and
disappearance of abnormal situations or events in the communication with
connected stations, printers and applications (STA, PRI and APL objects) or on the
communication lines (NET lines). A system message is always related to a certain
object or a line and it indicates:
• A malfunction in the object or line, e.g. an RTU is not responding
• A recovery after a malfunction
• An event, e.g. a S.P.I.D.E.R. RTU is restarted
The system message contains a code, which describes the state of the device or line
The status code 0 indicates OK status. A status code larger than 0 does not
necessarily indicate an error. The codes are listed in the manual Status Codes. The
codes related to system objects are 0 and the codes larger than 10 000. (The
explanation can be read in the Windows command prompt window with the
command: STATUS ‘error code’).
The system messages can be sent to an application in a base system, where the codes
can be updated in a process object and used for alarm or printout generation,
activation of control operations, etc.
System message generation

The NET unit itself can cause system messages containing the status codes 0,
10000 ... 12 099 and 16 600 ... 20176. System messages are generated, e.g. in the
following situations:
• The communication program has started: code 10001. This message is sent to all
applications defined in the unit.
• The Mail Update Identification (MU) attribute has been updated: code 16633.
See the System Objects manual, Section 12.7.
The application connection supervision in the NET unit can cause messages with
some special codes in the following situations:
• When the application communication is suspended: the application number. The
message is sent to the application defined by the Message Application (MS)
attribute of NET, or to the first application which is responding. See the
Application Suspension Time (SU) attribute in the System Objects manual,
Section 12.4.
161
• When the application communication is recovered: 1000 + application number.

The message is sent both to the recovering application and to the application
which received the suspension message.
NET lines, being independent of the protocol, can cause system messages with the
status codes 0 or 14001 ... 16099 and some of the codes 16101 ... 16599 and 16700
... 17999 depending on the protocol defined. The lines cause system messages, e.g.
in the following situations:
• Various situations on communication lines: protocol dependent codes. For
example, if no ACK is received on ANSI X3.28 Full Duplex lines, a message
with the code 16101 will be generated.
• Various situations on dial-up lines: see section 13.2.
• The line is taken into use (IU= 1). However, this does not concern all protocols.
• The NET-NET communication is lost: Peer NET number.
• The NET-NET communication is started: 1000+Peer NET number.
Stations using the ANSI X3.28 protocol (STA) can cause messages with the status
codes 0 or 12301 ... 12399. The stations cause generate messages, e.g., in the
following situations:
• The station is put into suspended state because it does not respond to poll packets
or messages: codes 12334, 12336, 12337, or 12386.
• The In Use (IU) attribute of the station has been set to 0: code 12339.
• The connection to a station, supervized by the DCD signal, has been lost: code
12333.
• The station connection recovers after a disturbance: code 0.
The S.P.I.D.E.R. RTUs (RTU) can cause messages containing the status codes 0
and 12601 ... 12749. Some situations cause codes which are a running number, 0 ...
999, kept be the communication unit. The system messages are generated, e.g., in
the following situations:
• The station is suspended: code 12602.
• The station recovers from suspension: code 0.
• The station is stopped or restarted: codes 12604 or 12605 respectively.
• Transparent data received: code 12683.
• Terminal status received: codes 12701 .. 12789.
• Terminal message received: codes 0 ... 999.
• Terminal event received: codes 0 ... 999.
A PRI object can cause messages with the status codes 0 and 13101 .. 13100.
System messages are generated, e.g. in the following situations:
• The printer is switched off: code 13119.
• The printer is off line or it has been busy for more than 10 seconds: code 13103.
The printer accepts data again after any of the above situations: code 0.
See the Status Codes manual for specific ranges of system messages.
162

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 this 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 on-line
and the MI attribute is not explicitly set, or if the MI attribute is set to 0 in the
preconfiguration. The default values are shown in Table 15.1.-1.
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 generation should only be disabled in special cases, e.g. if the base system
application program often executes commands which cause undesirable system
messages.
Application requirements
To use the system messages in an application:
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 will be
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 means of event, alarm and printout
attributes. See the Application Objects manual, Sections 3.2.6. and 3.2.7. for alarm
generation; 3.2.8. for activation of event channel and automatic updating in pictures;
3.2.10. for printout activation and 3.2.9. for including event history in the event list.
163
Table 15.1.-1 The default message identification (MI) attribute values

Object Message MI Default Value
NET itself General messages, e.g. start-up messages 6000 + NET no.
Value: Status code.
Application supervision. 6050 + NET no.
Value: APL no.= failure
1000 + APL no. = recovery
(APL no. as known to NET)
Redundant frontend supervision 5900 + NET no.
Value: Peer NET no. = failure
1000 + peer NET no. = recovery
NET line All NET line messages 6000 + 100 NET no. + line no.
STA, ANSI Stations All STA messages from ANSI stations. 1000 + STA no.
Value: Status code
STA, S.P.I.D.E.R. RTU General messages, e.g. station suspension, 8000 + STA no.
recovery, etc.
Value: Status code.
Terminal status 8500 + STA no.
Value: Status code.
Terminal message 9000 + STA no.
Value: Message tag number, 0 ... 999.
Terminal event 9500 + STA no.
Value: Event tag number, 0 ... 999.
STA, SPA units All STA messages from SPA stations 1000 + STA no.
Value: Status codes
PRI, printers All PRI messages 3000 + PRI no.
Value: Status code
15.2. Auto-dialling
Auto-dialling can be used on all NET serial lines defined for the ANSI X3.28 Half
Duplex or Full Duplex protocols, ACP (MicroPROTOCOL), Modbus, IEC 1107 or
the RP 570 protocol. Auto-dialling is for example useful:
• 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 must be configured and taken into use
on-line.
Create the line in the preconfiguration or on-line. 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 1107 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.
164
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 desired after a specified time, set the
Connection Time Limited (CL) and Connection Time (CT) attributes, for
example:
#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 the
System Objects manual, Section 13.6.
6. Set the In Use (IU) attribute of the line to 1, for example:
#SET NET1:SIU5 = 1
Dialling procedures
To dial up a workstation or RTU from a NET:
1. 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 will be generated. A failed dial-up generates the code 16704.
The connection to an RTU will be broken automatically, if the RTU becomes
inoperable, if it hangs up, or when the RTU is the dialling part,or if it has nothing to
send (after two subsequent CCR2 responses). In addition, the connection can be
broken automatically according to the Connection Time (CT) attribute. If the
connection is not broken automatically, break it as follows:
2. Set the Connection (CN) attribute to 0:
#SET NETn:SCNline = 0
A succeeded hang-up generates the system message with code 16733. If the hang-
up failed, the code 16702 or 16703 is generated. The status codes 16106, 16107 and
16810 indicates that disconnection has started.
165
Examples:
Dialling a MicroTERMINAL:
#SET NET1:SCN5 = "1234567"
Dialling station 11 (STA11):

#SET NET1:SCN5 = "1234567S11"
Breaking the connection:

#SET NET1:SCN5 = ""
15.3. Time synchronization

For exact and reliable operation, the whole chain between the process and the
MicroSCADA databases must be synchronized: the stations, the communication
units and the base systems.
The MicroSCADA base system works according to the operating system clock,
which is regularly set according to the physical clock of the base system computer.
If an external time synchronization source such as a radio clock or a GPS clock is
used, it sets the physical clock and the operating system clock regularly. The
operator can also set the system time, whereby both the operating system clock and
the physical clock are set simultaneously. However, if the computer uses an external
time synchronization source, the manual time setting will have a temporary effect
only, as the time is set regularly by the external time synchronization source. An
external time synchronization source of type radio clock can also be connected to a
frontend and a NET unit.
If the base system uses an external time synchronization source, not only the base
system itself, but also possible internal frontends are synchronized automatically.
Likewise, if a communication frontend contains a radio clock, all communication
units within the frontend are synchronized automatically. In both cases, the accuracy
is about 10 ms. Hence, if both the base system and the communication frontends are
equipped with radio clocks, no procedures for synchronising these are required, only
the stations must be synchronized from the connected NETs.
If the base system, but not the communication frontend, uses a external time
synchronization source, the NET units of the frontend must be synchronized, either
by synchronising the units individually, or by synchronising the frontend, whereby
all communication units are synchronized as well. The former method may be
preferable, as the accuracy of the NET units is 20 ... 30 ms, while the accuracy of the
frontend PC is about 60 ms. On the other hand, if the units are synchronized via the
frontend, the difference between the NET units will be small (<<= 10 ms). If the
frontend, but not the base system, contains an external time synchronization source,
the base system must be synchronized from a NET unit within the frontend.
The base system time can be read and written on millisecond level, with an accuracy
of 10 milliseconds, with the SCIL functions HR_CLOCK and SET_CLOCK. For
more information on the functions, see the Programming Language SCIL manual,
Section 8.3.
The time of the communication units and frontends can be read and written with the
NETn:STM attribute.
166
The time of the stations (S.P.I.D.E.R. RTUs and ANSI stations) are synchronized by
means of the Clock Synchronization (SY) attribute. SPACOM units are
synchronized automatically.
Synchronising NET from base system

The communication units can be manually synchronized from the base system
using NET ON-LINE CONFIGURATION tool, INTERNAL ATTRIBUTES and
the function key SYNC NET FROM SYS. The time synchronization program
regards the delays caused by the transmission and execution of the command. To
build an automatic regular synchronization of a NET from a base system:
1. Define a time channel with an appropriate time interval.
2. Define a command procedure to be started by the time channel and containing at
least the following commands:
@TIME = HR_CLOCK
#SET NETn:STM(1..2) = (TIME:VCL,ROUND(TIME:VUS DIV 1000))
which read the base system time and copy it to the NET time. In order to get better
accuracy, regard the transmission and execution delays. Use the program under the
function key SYNC NET FROM SYS in the SYSO_NNET.PIC picture as a model.
Synchronising stand-alone frontends

When started, the frontend time is set to the time of the PC clock. To synchronise a
communication frontend from a base system, include at least the following
commands in a SCIL program:
@TIME = HR_CLOCK
#SET NETn:STM = (YEAR, MONTH, DAY, HOUR, MINUTE, -
SECOND, TIME:VUS DIV 1000)
This does not regard the transmission and execution delays, it requires a more
extensive procedure.
Synchronising a base system from a NET

If the frontend or a NET unit is connected to an external time synchronization
source, when the base system is not, the base system must be synchronized from a
NET unit. To synchronise the base system regularly on a millisecond level, define a
time channel that starts a command procedure containing at least the following
commands:
@NET_TIME = NETn:STM(1..2)
@A =SET_CLOCK(
LIST(CL=CLOCK(%NET_TIME(1)),US=1000*%NET_TIME(2)))
This procedure does not regard the time delay required for executing the command
and communicating with NET.
Synchronising stations
To synchronise NET and a S.P.I.D.E.R. RTU200 or ANSI station, set the Clock
Synchronization (SY) attribute of the station, e.g. #SET STAn:SSY. For
S.P.I.D.E.R. RTUs, all the RTUs connected to one NET can be synchronized
simultaneously by using the broadcast station number. ANSI stations must be
synchronized individually.
167
SPACOM stations need no synchronization procedures, as they are synchronized

automatically from the connected NET.
The time synchronization accuracy on SPA and RP 570 lines varies from +-5 to +-
50 milliseconds, and on ANSI lines from +-10 to 1000 ms, depending on the station
type, the location of the station and the location of the external time synchronization
source.
15.4. Storing the event history

There are two ways to store the event history:
• Using history database
• Using event log and history buffer
The application engineer chooses one of them when he creates the application. The
HP attribute determines which one is in use. By default, the event log is chosen for
compatibility reasons. For new applications the value should be changed to
“DATABASE”. For more information about the HP attribute, refer to the System
Objects manual, Chapter 5 and for HISTORY_DATABASE_MANAGER function,
refer to the Programming Language SCIL manual, Chapter 8. The application
objects related to the subject are described in the Application Objects manual,
Chapter 3.
15.4.1. History database

History database consists of history database files, which each contain events of one
day. The files are named according to the date as APL_yymmdd.PHD. For example,
file APL_980115.PHD contains the events logged on 15-Jan-1998.
For fast access in time stamp order, there is an index file corresponding each data
file. The name extension of the index file is PHI. The history database is the basis
for event lists made by LIB 500 version 4.0.2.
The maximum size of the file is 32 MB. If the database file gets full, the files will
be renamed. File extension PHD is renamed to PHX and PHI is renamed to PHZ.
New empty files with extension PHD and PHI are created and the logging
continues to these new files. If PHX or PHZ already exists, the contents of PHD
and PHI will be lost. The application is informed by generating an APL_EVENT
with the following arguments:
source "HISTORY_DATABASE"
source_nr Status code of the failing write operation
event "FULL"
Each event in the history database contains all the attributes of the process object,
except for CX attribute. Additionally, it contains extra attributes listed in Table 2.
Table 15.4.1-1 History database specific attributes
ET Event Time
EM Event time Milliseconds
ED Event Daylight saving
HT History logging Time
HM History logging time in Milliseconds
168
HD History logging Daylight saving

CA Changed Attribute
EX Event comment teXt
For more information about these attributes, see Chapter 3 in the Application
Objects manual.
Configuration
Define the HP attribute as "DATABASE". History database requires no special
configuration, in addition to this. Note that the HL attribute has no meaning, if
APL:BHP == "DATABASE".
15.4.2. Event log

An event log is a disk back-up of the event buffer. The events included in the log are
specified on process object basis. Each time an event occurs in a process object
defined for the event log, its attributes are written to the log as a text line. The history
buffer or the history log is the basis for event lists made by LIB 500 version 4.0.1 or
earlier versions of application libraries.
Note that event log supports names that contain 10 characters and values of IX < 999
or OA < 99999. If longer names are used, the names will be shortened and the object
name with the following warning is written in the Notification Window
“WARNING: Long text has been truncated during event logging.” If longer
numerical values are used, the value will be changed to zero and a similar warning
will be created. For more information on logging, see the Application Objects
manual, Section 3.2.9.
Configuration
To build an event log on disk, create a PRIn:B base system object with the
following attributes:
Device Type DT “NORMAL”

Device Connection DC “LINE”
Lines per Page LP 0
Translation Type TT “LOCAL”
Output Destination OD “LOG”
Log Directory LD The directory where the log is stored
Log Flush Timeout LF
Log Length LL “DAY”, “WEEK”, “MONTH” or
“YEAR”.The period that the logging is stored
in the same file. Event log handling becomes
slower, the larger the file is. Therefore, if the
event frequency is high, “DAY” or “WEEK”
should be used. “MONTH” or “YEAR” can be
used only, if the events occur rarely.
169
For detailed information on the attributes, see the MicroSCADA System Objects
manual, Chapter 10.
The event log files are not destroyed by MicroSCADA, but should
be deleted manually when no longer needed.
1. If needed, map the printer to be known to the application by another number.

The printer must not be used for other printout purposes. If the event list is built
with MicroLIBRARY, the printer should be mapped to logical printer number
15.
2. Set the History Log Number (HL) attribute of each process object that will be
included in the event log. The number is given as a bit mask. For more
information on the HL attribute, see the Application Objects manual.
170
16. System Configuration Tool

This chapter describes the System Configuration tool that is situated in the
MicroSCADA Tool Manager System Configuration page.
This tool manages the configuration of the following objects:
• Integrated link for PC-NET
• PC-NET
• LonTalk (LON), SPA, IEC, DNP 3.0, ANSI X3.28, LCU500, RP 570, RP 571,
ASCII Printer, MODBUS RTU and MODBUS ASCII protocol lines
• REx, SPA, LMK, IEC, DNP 3.0, STA, LCU 500, SPI, PLC and RTU stations
• LON Clock Master and LON Star Coupler
16.1. Main functions

The System Configuration tool includes the following main functions:
• Configuration of the base system and the PC-NET(s)
• General mechanism for the base system configuration at system start-up
• General mechanisms for automatic starting and configuration of the PC-NET(s)
• Online monitoring of the base system and the NET configurations
• Configuration of transceiver information and node and subnet numbers of the
PCLTA card
• Debug support
The System Configuration tool can handle base system objects such as links, nodes,
stations and station types. It can operate in the on-line or off-line mode. A
combination of the two is not supported. When operating in the off-line mode, a
configuration can be set up without physical connections to the devices. If the tool
is switched to the on-line mode, the existing configuration is read from the current
MicroSCADA base system. Stopping and starting the NET and the initialization of
the PCLTA card can only be done in the on-line mode.
During the configuration, the configuration data is read from the permanent
configuration file using the off-line reading mechanism, or from the MicroSCADA
system (SYS 500 or COM 500) using the on-line reading mechanism. The tool does
not distinguish between the two methods of reading the data. After the data has been
read, the current configuration is displayed in the tool.
System Configuration tool includes a function which checks the attribute limits. If
there is an invalid attribute value, it returns a string, which requests the user to enter
a valid value. The tool also suggests default values for the attributes.
Debug support
For debug support, System Configuration tool provides a mechanism to view the
interpreted command lines, which are constructed from the configuration view.
In case of invalid configuration interpretation, possible SCIL errors are echoed in the
MicroSCADA Notification window. SCIL errors are also saved in a log file.
171
16.2. Starting the tool

To start the System Configuration tool, double-click the System Conf tool icon in
the MicroSCADA Tool Manager System Configuration page (see Fig. 16.2.-1).
Fig. 16.2.-1 System Configuration tool on the System Configuration page of

MicroSCADA Tool Manager
The System Configuration tool page includes a menu bar and a toolbar, which can
be selected from the Settings > Toolbar Visible menu. Below the toolbar, there is an
object tree on the left, an attribute tree in the middle and an attribute editing area on
the right hand side. In addition, there is an information text bar and a status bar at
the bottom of the page.
SCTPage1
Fig. 16.2.-2 Menu bar, tool bar, object tree and an attribute tree in the System
Configuration tool
16.3. How to handle the object and attribute trees

When an object is selected from the object tree, all the attributes linked to it are
shown in the attribute tree (if All Attributes is selected as the View option), (see
Fig. 16.2.-2). The working order is from left to right: after selecting an object in the
object tree, an attribute can be selected in the attribute tree and the selected attribute
can be edited in the attribute editing area.
172
A tree can be expanded by clicking the + sign on the left or double-clicking the text
area on the right. Likewise, the tree can be collapsed by clicking the - sign or double-
clicking the text area. The - sign means that the branch of the tree cannot be
expanded any further.
The whole attribute tree can be expanded and collapsed using the + and - buttons that
are situated below the tree (see Fig. 16.3.-1).
Fig. 16.3.-1 The Expand and collapse buttons for the attribute tree
16.4. How to save a configuration from a former release

If a configuration from a former MicroSCADA release is read into the System
Configuration tool, it can be saved with the Configuration > Save Active command.
It will be saved in the 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 taken in use.
16.5. How to create a new configuration

From the menu bar, choose Configuration > New.
This command opens a configuration that is delivered with the System
Configuration tool. It includes an Object tree with Link 3 (INTEGRATED) and
Node 3 (NET), (see Fig. 16.2.-2).
If there is a configuration open in the tool already, all the configuration data will be
cleared from the tool and the contents of the Object tree will be replaced with the
default configuration. To save the open configuration first, the Sysconf.ini and
Signals.ini files in the sys/active/sys_ folder should be copied or renamed.
173
16.5.1. Methods for adding new objects

1. From the object tree, select a parent object for the new object.
Node3
Fig. 16.5.1.-1 Node 3 (NET) selected to be the parent object

After you have selected a parent object, there are three ways of adding objects to the
configuration.
2. Use one of the following methods:
• Use the keyboard command Ctrl+N
• Use the menu bar command Object - New (see Fig. 16.5.1.-2)
Fig. 16.5.1.-2 A new object is added by using the menu bar command
• Click the Object creation tool icon in the toolbar
3. Select the object type and click Insert.
174
Fig. 16.5.1.-3 A LON Line will be added to the configuration

4. Enter the object number in the text box and click OK (see Fig. 16.5.1.-4).
Fig. 16.5.1.-4 Number five is entered for the new line object
The new object is added to the object tree.
Fig. 16.5.1.-5 A new LON line is added
16.5.2. Adding a redundant line

The tool supports adding redundant line for IEC 60870-5-101 and RP570 slave lines.
Select the line (IEC 870-5-101 Slave Line or RP570 Slave Line) from the object tree
and then select Object > Add Redundancy.
175
Fig. 16.5.2.-1 Adding the redundant line

Enter the line number of the redundant line in the field.
Fig. 16.5.2.-2 Enter the line number of the redundant line

The redundant line is added to the object tree.
Fig. 16.5.2.-3 Redundant line configuration
16.6. Default configuration

The default configuration is stored in a configuration file called Sysconf.ini.
To open the default configuration file:
From the menu bar, choose Configuration > Open Active.
176
The default configuration is loaded in the tool. The tool is opened in the off-line
mode, which is shown in the status bar.
To save a configuration as the default configuration:
From the menu bar, choose Configuration > Save Active.
This command saves the configuration currently open in the tool as the default
configuration in the Sysconf.ini file. The configuration can be saved at any time and
this can be done in both the on-line and the off-line mode.I
In the on-line mode, only the objects that are In Use are saved with
Configuration > Save Active command.
16.7. On-line configuration

The on-line configuration is the current configuration in the MicroSCADA system.
Loading:
To load the current MicroSCADA system configuration in the tool, choose
Configuration > Open Online.
This changes the System Configuration tool to the on-line mode. The back-
ground color of the object and attribute trees are set to "Lavender" and the
text in the lower rigth corner is changed to “Online” when the Online mode
is selected.
Under MicroSCADA Configuration node there is a node called Station Type
Definitions (see Fig. 16.7.-1). This object includes all the different station types and
it appears, when the MicroSCADA Configuration node is expanded. Deletion of this
object is not possible.
177
Online1
Fig. 16.7.-1 Station type definitions in the on-line configuration
Saving:
If the online configuration is saved using the command Configuration > Save
Active, the following notification dialog appears on the screen:
"Saving the on-line configuration overrides current active configuration in
files. If e.g. some stations do not communicate in the on-line mode for some
reason, they are removed from the active configuration. Proceed?"
• Clicking Yes overrides the current active configuration in the System
Configuration tool and saves the online configuration as the default
configuration.
• Clicking No cancels the saving operation.
If the menu bar command Configuration > Save Active is selected, the
configuration must include a Link object and a NET Node object related to the
Link.
178
If the Link object and/or the NET Node object are not present, the
PC-NET wil not start up successfully. Therefore, it is not possible to
save this kind of invalid configuration with the Save > Active
command.
How to change the attribute values

When an object is selected from the configuration tree, all the attributes linked to
that object are shown in the attribute tree (if All Attributes is selected as the View
option).
The attribute tree consists of attribute groups, which can be expanded to show all the
attributes in the group. The attribute tree can be expanded and collapsed using the +
and - buttons that are situated below the tree. The attributes are illustrated by an icon,
a two-letter abbreviation, name and the valid value.
Attr.tree1
Fig. 16.7.-2 Some of the MicroSCADA Configuration item attributes in the

expanded attribute tree
The attributes are given default values by the tool. Most of the values can be
changed. However, if the value in the editing area is shown dimmed, no editing is
allowed.
179
The working order is 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 and press Enter.
In the attribute editing area, the on/off values have a check box. An empty check box
means off (0) and a checked check box means on (1). For integer values, there is a
numeric spinner in the editing area (see Fig. 16.7.-3).
The attribute tree is updated, when changes are made in the editing area.
PS_attribute
Fig. 16.7.-3 Editing the PS attribute value with the numeric spinner
16.7.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
Configuration tool will be 255.
16.8. How to take a configuration in use or 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.
Likewise, all the stations must be taken out of use before the line is taken out of use.
To take the configuration in use, you have to change the IU attribute values to In Use
mode in the System Configuration tool:
1. From the menu bar, choose Configuration > Open Active (if it is not open
already).
2. In the Object tree, select the line you want to take in use (see Fig. 16.8.-1).
180
LON_line5
Fig. 16.8.-1 The LON line number five is selected in the Object tree
3. Double-click the text Basic Line Attributes (or click the + sign beside the text)
in the Attribute tree (see Fig. 16.8.-2).
This will expand the Basic Line Attribute group and show all the attributes in it.
LON_attrib
Fig. 16.8.-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, click the IU check box checked (In Use state).
InUseState1
Fig. 16.8.-3 IU Attribute in the In Use (1) state

5. Choose 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.
181
16.9. How to delete an object

Objects can be deleted from the Object tree by selecting the object and choosing
Object > Delete from the menu bar (or pressing Ctrl+B on the keyboard).
If the object includes user-defined SCIL programs or signals, those are deleted as
well.
Delete_station
Fig. 16.9.-1 Station 2 will be deleted

The main object (MicroSCADA Configuration object) cannot be deleted.
16.9.1. How to delete a redundant line

A redundant line (IEC 870-5-101 slave or RP570 slave) can be deleted by selecting
the line or the redundant line and by choosing Object > Remove Redundancy from
the menu bar.
Remove_redu
Fig. 16.9.-2 Remove the redundant line
16.10. Cut, copy and paste functions; reallocating stations

It is possible to cut, copy and paste the already defined objects in the configuration
tree. When the Cut operation is chosen, the copied object is also deleted from the
configuration tree.
During the Cut/Copy and Paste operation 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 (REx, LMK and SPA points).
182
Cut and Copy

1. Select the object to be cut or copied from the configuration tree.
2. Choose Edit>Cut or Edit>Copy from the menu bar.
The selected object will be cut or copied to the clipboard.
During the Edit-Cut/Copy operation the contents of the signal data for the REx,
LMK, SPA and LON Clock Master devices, as well the data structure, is assigned
to the clipboard.
Cutting of an object will not be possible, if the selected object

includes child objects.
Paste
1. In the configuration tree, select the parent object for the object on the clipboard.
2. Choose Edit > Paste from the menu bar.
The pasted object will be 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 and LON Clock Master devices 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.
Paste As Range
The configuration object that was copied into the clipboard can be pasted several
times. The paste object number collection is based either on the definition of the
minimum and maximum object numbers (e.g. from 1 to 10) or on the definition of
individual object numbers (e.g. 4, 5, 8, 10). The Paste As Range function can be
found in the Edit menu.
Paste_as_range
Fig. 16.10.-1 The minimum object number is defined to be 1 and the maximum
object number 10
183
If the copied object includes a set of child objects (e.g. copied LMK station includes
several SPA stations), the pasting of the object (LMK station) does not include
pasting of the child objects (SPA stations). If there is a need to copy also the child
objects, they have to be copied separately.
System Configuration tool includes error handling during the pasting of objects.
16.11. Preview function

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:
From the menu bar, choose Configuration > Preview.
Preview_options
Fig. 16.11.-1 Preview options

The SCIL clauses are displayed in the SCIL Editor.
SCIL programming is NOT possible by using the Preview function.
16.12. User-defined programs

It is possible to make user-defined SCIL programs for the NET Node, NET Line and
Stations. With these programs it is possible to modify lines and process units with
features, which are not yet supported by the configuration tool. For the NET, you
can create protocols and devices, which are not yet supported for the lines in the
System Configuration tool.
Preview_options2
Fig. 16.12.-1 The symbol for the user-defined programs is disabled
184
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
program.
• 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.
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. From the menu bar, choose Program > User-Defined.... (see Fig. 16.12.-2).
Open_SCIL_editor
Fig. 16.12.-2 The SCIL Editor will be opened

3. Edit your program using the variables listed in the comments of the program.
SCIL_editor
Fig. 16.12.-3 Net3.scl file in the SCIL Editor

4. Update and exit the program editor.
185
16.13. General object handling command

This attribute is included in the System Configuration tool, when the tool is used in
the on-line mode.
1. Select a REx station in the Object tree.
2. Choose Tools > General Object Handling Command.... from the menu bar (see
Fig. 16.13.-1).
Fig. 16.13.-1 The General Object Handling Command dialog will be opened
A dialog box is opened (see Fig. 16.13.-2).
3. Enter the appropriate values.
If you click Send, the command will be send to the selected REx Station. The Close
button closes the dialog without sending any command.
Example:
Fig. 16.13.-2 General Object Handling Command dialog with example values
If you enter the same value definitions that you can see in the above dialog (see
Fig. 16.13.-2) and click Send (or press ENTER on the keyboard), the following
SCIL command will be send to the REx station number one:
#SET STA1:SGO = (1, 1342, 3, 4, 2, 0, 1)
186
16.14. Environment
The attribute tree definitions and PC-NET Start-up delay time can be set in the
Environment dialog.
Fig. 16.14.-1 The 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.
16.15. System Self Supervision with Monitor Classic

System Self Supervision is always dedicated into certain MicroSCADA application,
i.e. into sets of command procedures, event channels, time channels, process objects,
data objects and parameter files. System Self Supervision functionality can be
enabled in the MicroSCADA application, either installing the first picture function
from the LIB500 System Self Supervision package or by selecting the enabled state
from the System Self Supervision dialog in the System Configuration Tool.
In the System Configuration tool, choose Settings > System Self Supervision from
the menu bar. The following dialog opens:
187
Fig. 16.15.-1 In this dialog system self-supervision can be enabled or disabled

When the System Self Supervision functionality is enabled in MicroSCADA
application, the System Configuration Tool does not create supervision routing
objects for all the included configuration objects by default. This means that the user
has to select the appropriate option from the dialog. To be able to remove the
supervision routing objects from the previously included configuration objects, it
also requires setting of that option in the System Self Supervision dialog.
If no picture function is installed from the LIB500 System Self Supervision package
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, to remove
supervision routing from all the previously included configuration objects, requires
also setting of 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.
(see Fig. 16.15.-2). To enable the system self-supervision routing, the base system
object definition (SYS:B) has to include a new attribute called
B_SSS_MECH_IN_USE. An example of this attribute can be found from the new
template in the file SYS_BASCON$COM.
Fig. 16.15.-2 This dialog informs the user that the current SYS_BASCON.COM
template must be replaced to enable the system self-supervision
188
When the old SYS_BASCON.COM is used during the start-up of MicroSCADA,

the editing of the System Self Supervision dialog is disabled.
If a new SYS_BASCON.COM template is being used during the start-up of
MicroSCADA, it is possible to stop and start the run-time supervision routing in the
application. Stopping and starting is done by using the appropriate dialog item in the
bottom of System Self Supervision dialog. An information dialog is displayed to tell
if the starting or stopping of the run-time supervision was successful or not.
Supervision log
The System Configuration Tool includes also access to Supervision Log. To enter
the Supervision Log dialog, choose Tools > Supervision Log from the menu bar
The Supervision Log displays all the different events in MicroSCADA and the
Windows system (see Fig. 16.15.-3). 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, choose 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, e.g. events from a certain station number.
189
Fig. 16.15.-3 MicroSCADA Supervision Log in the System Configuration tool
16.16. System Self Supervision with Monitor Pro

The System Self Supervision (SSS) is used in MicroSCADA systems for
supervising and monitoring the system. It provides the status information of
hardware and software by using the symbols of SYS 600 Monitor Pro.
System Self Supervision consists of
• Supervision Application Objects
• Supervision Monitoring
Supervision application objects contain the source for supervision information to be
displayed by supervision monitoring in supervision display.
190
Supervision_disp
Fig. 16.16.-1 Example supervision display
16.16.1. Supervision Application Objects

The role of supervision application objects is to acquire the communication status of
components to be supervised in the system. It is preferable that the status should be
provided in a binary way, i.e. one value indicating a good status, and another value
indicating bad status. In this way, the dynamic coloring logic of supervision display
symbols would be more straightforward to define.
For textual or numeral information, the related base system object (SYS, MON, APL
or PRI) should be used as a source for information to be displayed.
Table 16.16.-1Proposed application objects for System Self Supervision

Functionality Application Object Access Path Examples
Base System SYS:Bnn attributes and SYS:BNN, SYS:BND, SYS:BSA
SYS_Nnnnn:P10 process objects SYS_N0009:P10, SYS_N0010:P10
Monitor Classic MONn:Bnn attributes and MON1:BTT, MON5:BDT, MON3:BLA
APLn:Bnn attributes or APL1:BMO(1), APL1:BMO(5)
SYS_Mnnnn:P10 process objects SYS_M0001:P10, SYS_M0005:P10
Application APLn:Bnn attributes
191
Table 16.16.-1Proposed application objects for System Self Supervision

Communication SYS_NnnnnI:P10 process objects
Communication Line SYS_NnnnnI:P1nn process objects
Station SYS_SnnnnI:P10 process objects
LON Clock Master SYS_SnnnnI:P10 process objects
Printer PRIn:Bnn attributes
Communication
The application object source for communication depends from used component
(IEC 61850 or PC-NET) in MicroSCADA system.
• For IEC 61850 OPC Server, the supervision should be based on mapping of
specific OPC Item found from the IEC 61850 OPC Server
• For PC-NET, the supervision should be based on cyclical reading of PC-NET
internal communication line
In both of these cases, the binary input process object should be found from the
process database.
Station
The application object source for station object supervision depends from the
protocol used in MicroSCADA system.
• When there are stations connected through IEC 61850 communication protocol,
the supervision of stations should be based on mapping of Device Connection
Status OPC item found from the IEC 61850 OPC Server
• In the case of all other protocols, the supervision of stations should be based on
mapping of system message process object received from PC-NET
Again, in both of these cases, the binary input process object should be found from
the process database.
16.16.1. Supervision Monitoring

The main function of supervision monitoring is to provide the supervision of
running system through dynamic symbols.
16.16.1.1. Proposed SA symbols

The default Palette of Display Builder contains a set of symbols, which are proposed
to be used as SA symbols for System Self Supervision, see Table below. Because,
these symbols act as a static symbols, there is need to add the dynamics separately.
Table 16.16.1.1-1Proposed SA symbols for System Self Supervision

Functionality Symbol File Name Palette Tab
Base System Angled PC.sd 91 - Computers
Monitor Classic Monitor.sd 91 - Computers
Communication Line Line.sd 97 - International
192
Table 16.16.1.1-1Proposed SA symbols for System Self Supervision

Station IED.sd 01 - SA_Common
LON Clock Master Satellite dish -white-.sd 91 - Computers
Printer Laser printer.sd 91 - Computers
16.16.1.2. Dynamics
When dynamics is added to the supervision symbols, they start to reflect the
communication status of components in the system. The following issues need to be
taken into consideration:
• Object and location of dynamics in symbol
• Settings for dynamics
• Usage of own Palette
• Saving of supervision display
Object and location of dynamics in symbol
Following chapters describes the possible dynamic objects to be used for
supervision symbols, and principles about location of these objects related to static
supervision symbol.
Object in symbol
Select some of the items found from the Objects toolbar of Display Builder to be
used, when including the dynamics into supervision symbol.
Obj_toolbar
Fig. 16.16.1.2.-1Objects toolbar
193
Location inside the symbol

For some supervision symbols it may be useful to combine the dynamics inside the
symbol itself producing the compact symbol with dynamics.
In the below figure, the green color indicates active monitor (operator logged on),
whereas the grey color indicates a passive monitor. The Polyline object from Objects
toolbar has been used.
Inside_dynamics
Fig. 16.16.1.2.-2Supervision with inside symbol dynamics
Location beside the symbol

If there is no suitable area inside the supervision symbol that could be used for
dynamics, it is proposed to use e.g. Rectangle or Circle, beside the symbol. In the
below figure, the static symbol has been adjusted with the Rectangle object
including dynamics.
Beside_dynamics
Fig. 16.16.1.2.-3Supervision with beside symbol dynamics
Settings for Dynamics

In the Dynamic tab of Display Builder, the related Data Variable for source
application object is mapped to the selected property of an object. In the figure
‘Dynamic settings for...’ below, the Data Variable MON 2 Status has been mapped
to the Foreground property of a Polyline object.
It is also possible to map Data Variable to a memory type of data

variable. Then in the supervision display these memory type of data
variables are mapped to MicroSCADA application objects per
instance..
194
Polyline_obj
Fig. 16.16.1.2.-4Dynamic settings for Polyline object
For the object there is need to introduce the Min and Max values. Using the
Threshold Editor, the possible values of Data Variable are mapped to use certain
colors, see the figure below.
Table 16.16.1.2-1Proposed threshold colors

Color Index Description
Green 32 Logical normal color, green by default
Red 46 Logical alarm color, red be default
Grey 14 Grey by default
195
Threshold_editor
Fig. 16.16.1.2.-5Threshold settings for values
When the threshold values have been introduced for some supervision symbol type,
use the Save button of Threshold Editor to save these definitions into threshold file.
Then later on, load this threshold file for every supervision symbol of this same
threshold value semantics.
Usage of Own Palette
To increase the productivity, when building-up supervision display, the most
efficient engineering is achieved, when these proposed SA symbols are taken as a
source, and extended with dynamics.
Create a new folder with name 11 - Supervision into
\sc\prog\graphicsEngine\Palette folder. Then include all the supervision sub-
drawing files with bitmap files into this folder. The 32 x 32 pixel bitmaps can be
created with any applicable software that is able to save in 256 color 8-bit BMP
format.
196
Note that next time, when Display Builder is started, the Palette folders appear in
alphabetical order. To hide the bitmap files in the tab do the following. Select a
bitmap file, select Hide Item from the pop-up menu accessed from the right-mouse
button.
Supervision_palette
Fig. 16.16.1.2.-6Supervision Palette
When later instantiating the supervision symbols, select the symbols from this tab.
Then, when connecting the symbol to the related application object, use the Open
Subdrawing menu item of pop-up menu, when symbol is selected in the Display
Builder.
Saving of Supervision Display
Before saving, select all graphical objects and click Actions > Remove Selected
Objects from Topology. This ensures that Busbar Coloring ignores the supervision
display in Monitor Pro.
16.16.1.3. Base System Supervision

When SYS:Bnn attributes are used as a source for base system supervision, the
following semantics could be utilized to provide additional information beside the
base system symbol itself.
Table 16.16.1.3-1SYS:Bnn attributes

Attribute Description Functionality
NN Node Name Name of the Computer
ND Node Number MicroSCADA Node Number
SA Station Address MicroSCADA Station Address
197
When process objects are connected to the predefined event channel SYS_EVENT,
the binary information is used as a source for base system supervision with
following semantics.
Table 16.16.1.3-2Process objects related to SYS_EVENT (Binary Input)

Value Description Function
0 FOUND Connection to the node is re-established
1 LOST Connection to the node is lost
Command Procedure
An example of the command procedure to be attached into predefined event channel
SYS_EVENT
#case %SOURCE
#when "NOD" #block
#case %SOURCE_NR
#when 9 #block
#if %EVENT == "LOST" #then #set SYS_N0009:POV10 = 1
#else #set SYS_N0009:POV10 = 0
#block_end
#when 10 #block
#if %EVENT == "LOST" #then #set SYS_N0010:POV10 = 1
#block_end
#case_end
#block_end
#case_end
Mapping of Data Variables

Map the related process objects, e.g. SYS_N0009:P10 and SYS_N0010:P10, to the
Foreground Color property of a Polyline object. Use value 0 as an indicator of OK
status (green), and value 1 as an alarming status (red).
Example
Sup_base_syst1
Fig. 16.16.1.3.-1Supervised base system example.
16.16.1.4. Monitor Classic Supervision

When MONn:Bnn attributes are used as a source for monitor supervision, the
monitor symbol itself.
Table 16.16.1.4-1Monitor Mapping of an Application

TT Translation Type Translation type of the monitor
198

DT Display Type Display type of the monitor
LA Language Language of the operator
When monitor mapping of application (APLn:BMONnn) is used as a source for
monitor supervision, the following semantics is found from the attribute value.

Value Functionality
-1 Monitor not in use
> 0 and <151 Monitor in use
Example
Sup_monitor
Fig. 16.16.1.4.-1Supervised monitor example.
16.16.1.5. Communication
The application objects related to communication depends in which way the
communication occurs to the MicroSCADA system.
PC-NET
The status of PC-NET should be supervised through a cyclical period. The
application object for PC-NET supervision could be process object updated through
time channel.
Table 16.16.1.5-1Process object related to PC-NET (Binary Input)

Name Functionality
SYS_N0003:P10 Contains the communication status of
PC-NET
The semantics of process object could be the following.
Table 16.16.1.5-2Semantics of process object

Value Purpose
0 PC-NET communication error
1 PC-NET communication OK
Command Procedure
An example of the command procedure to be attached into time channel to supervise
the PC-NET
@i_Timeout = timeout(1000)
#error ignore
@i_Status = status
@i_IU = NOD3:SSA
199
#error stop
@i_Timeout = timeout(%i_Timeout)
#if status == 0 #then #set SYS_N0003:POV10 = 0

16.16.1.6. Communication Line

The application objects related to communication line depends in which way the
communication line is connected to the MicroSCADA system.
• OPC DA CLient
• IEC 61850 OPC Server
OPC DA Client
The supervision of OPC DA Client is done by reading the related Object Status
(STAn:SOS) attribute. You can also create a related process object to receive the
same information as the system message. Originally, the received value is returned
from the OPC server. The following codes can be received from the OPC server:
Table 16.16.-2 OPC Status code description

OPC_STATUS_RUNNING The server is running normally.
OPC_STATUS_FAILED A vendor specific fatal error has occurred within
the server.
OPC_STATUS_NOCONFIG The server is running, but it has no configuration
information loaded and therefore cannot function
normally.
OPC_STATUS_SUSPENDED The server has been temporarily suspended via
some vendor specific method and is not
receiving or sending data.
OPC_STATUS_TEST The server is in Test Mode. The outputs are
disconnected from the real hardware, but the
server will behave normally otherwise.
The codes are converted to the appropriate MicroSCADA status codes. The
correspondence of the codes is the following:
Table 16.16.-3 MicroSCADA status codes

OPC MicroSCADA
Status Status code name Status code
OPC_STATUS_RUNNING OK_STATUS 0
OPC_STATUS_FAILED SPAP_DEVICE_SUSPENDED 13251
OPC_STATUS_NOCONFIG SPAP_DEVICE_SUSPENDED 13251
OPC_STATUS_SUSPENDED SPAP_DEVICE_SUSPENDED 13251
OPC_STATUS_TEST SPAP_DEVICE_SUSPENDED 13251
200

When communication line is connected to the MicroSCADA through IEC 61850
OPC Server, the process objects mapped to the Object status OPC Item per IEC
61850 Subnetwork should be used.
Table 16.16.0.0-1Process objects related to communication line in IEC 61850

OPC Server (Analog Input)
Name OPC Item Example
SYS_N0003:P10 IEC61850 Subnetwork\Attributes\Object
status
When above process object is used as a source for communication line supervision,
the following semantics is found from the attribute value.
Table 16.16.0.0-2Semantics of process objects

Value Functionality
89 Initialize error
90 Not connected
91 Initializing
100 Ready
101 Suspended (=not in use)
102 Simulated
16.16.0.1. Station
The application objects related to station supervision depends in which way the
stations are connected to the MicroSCADA system.
• PC-NET
• IEC 61850 OPC Server
PC-NET
When stations are connected to the MicroSCADA through PC-NET, it is possible to
use the related STAn:Bnn attributes together with process objects updated by the
system messages from PC-NET.
When STAn:Bnn attributes are used as a source for station supervision, the
station symbol itself.
Table 16.16.0.1-1STAn:Bnn attributes

CX Comment Text Comment Text of the station
ST Station Type Type of the station
The system message process objects should be created according to the definitions
in the Application Objects manual.
201

When stations are connected to the MicroSCADA through IEC 61850 OPC Server,
the process objects mapped to the Device connection status OPC Item per IED
should be used.
Table 16.16.0.1-2Process objects related to IEDs in IEC 61850 OPC Server

(Binary Input)
Name OPC Item Example
SYS_S0001:P10 IEC61850 Subnetwork\AA1CP2\Attributes\Device connection status
SYS_S0002:P10 IEC61850 Subnetwork\AA2CP2\Attributes\Device connection status
When above process objects are used as a source for station supervision, the
following semantics is found from the attribute value.
Table 16.16.0.1-3Semantics of process objects

Value Functionality
0 Communication error
1 Communication is OK
NOT_SAMPLED_STATUS Status of communication not known. If the related In Use
OPC Item (e.g. IEC61850 Subnetwork\AA1CP2\Attributes\In
Use) is In Use state, this indicates the communication error.If
the related OPC Item is Not In Use state, this indicates the
configuration error.
Mapping of Data Variables

Map the related process objects, e.g. SYS_S0001:P10 and SYS_S0002:P10, to the
Foreground Color property of a Polyline object. Use value 0 as an indicator of
alarming status (red), and value 1 as OK status (green). The default value for
Polyline could be grey to indicate the possible not known status of communication
situation.
Example
Sup_station
Fig. 16.16.0.1.-1Supervised station example.
16.16.0.2. LON Clock Master

When STAn:Bnn attributes are used as a source for station supervision, the
station symbol itself.
Table 16.16.0.2-1STAn:Bnn attributes

CX Comment Text Comment Text of the station
ST Station Type Type of the station
202
16.17. Signal engineering

System Configuration tool is integrated to subtools for handling signal information
for devices. For each device type, there is a corresponding configuration tool for
managing signal information. These subtools can be launched by selecting Tools >
Signal Engineering... from the menu bar. The configuration page that is opened
includes all the signal information for the selected station.
The signal information transfer from the subtool is executed by choosing
Configuration/File > Update from the subtool’s menu bar. Information is also
transferred to the System Configuration tool, when Configuration/File > Exit is
chosen. In each of the subtools, there is a possibility to cut, copy and paste signal
information.
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 an enabled symbol exists, the selected object will include signal information.
• If a disabled symbol exists, it will be possible to include signal information for
the selected object, but no signals has been created yet.
• If no symbol exists, it will not be possible to include signal information for the
selected object.
Fig. 16.17.-1 The indicator shows that the selected object includes signal
information
16.17.1. Signal engineering on station level

The following features are common to all devices:
• When a station is selected in the configuration tree, the attribute area becomes
updated.
• The signal information of the selected station can be seen, if Tools - Signal
Engineering... is chosen from the menu bar. This operation opens the station
Configuration page.
• Managing the signals is performed via 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 the Online mode the buttons Add..,
Edit.. and Delete are disabled and the signal configuration can be viewed but not
modified.
203
Add/Edit
Add and edit functions 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 chosen, these signals are saved into the configuration files and
they become a part of the configuration data. The device signals are interpreted
automatically, when the NET communication is starting.
• SCIL commands which are constructed from the device signals, can be seen by
choosing Configuration - Preview... from the System Configuration tool menu
bar.
To edit signal information:
1. In the Object Tree, select the station to be engineered.
2. Choose Tools - Signal Engineering... from the menu bar (see Fig. 16.17.-2).
The station configuration page opens and it can be edited.
Fig. 16.17.-2 The station configuration page will be opened
Advanced page; topic configuration

In some stations (PLC, for example), topic configuration is shown in the Advanced
page.
204
Fig. 16.17.-3 The topic information of a PLC station is shown in the Advanced
page of the System Configuration tool
A new topic item can be added by clicking Add, which opens the Add Topic Item
dialog (see Fig. 16.17.-4). 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.
Fig. 16.17.-4 New topic item Object Command is to be added to a PLC station
Existing topic items can be deleted by selecting the appropriate item in the list and
by clicking Delete. Before the delete operation 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.
205
An existing topic item is edited by selecting the appropriate topic item in the list and
by clicking Edit... or double-clicking the topic item. The selected topic items are
displayed in the Topic Configuration Editor with the existing definitions (see
Fig. 16.17.-5). In this dialog, the topic type, allocation, first object address, last
object address, base address, format, interval and deadband are defined.
Fig. 16.17.-5 In this dialog, an existing topic item can be edited

Note that with indication type, one object address (OA) contains 16 bits and it
includes both single and double indications.
Allocation
This item specifies if 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

This parameter 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

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
The address of first item of topic in the device's memory. Values: 0 … 65535.
Format
Specifies how the data is stored in an external device.
206
Interval
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 will not be polled. Values: 0 …
65535.
Deadband
If the type of topic is an analog value, then the deadband value is used to minimise
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.
Advanced page: Memory Area Configuration

For STA stations the memory area configuration for data items is defined in the
Advanced page (see Fig. 16.17.-6).
Fig. 16.17.-6 The memory area configuration of STA station is shown in the Advanced page of the System
Configuration tool
A new item can be added by clicking the Add button, which opens the Add Memory
Area Item dialog (see Fig. 16.17.-7). In this dialog, the default type is binary input
or the type of the last added item. If STA station already includes thirty items, the
Add button is disabled, because the maximum number of the memory area items for
each STA device is thirty.
207
STA_Advanced2
Fig. 16.17.-7 New memory area item, Binary Input, is to be added to the STA
station
The existing memory area items can be deleted by selecting the appropriate item in
the list and by clicking Delete. Before the delete operation is done, a notification
dialog is displayed to the user. Clicking Yes deletes the selected memory area item
and refreshes the list. Clicking No cancels the delete operation.
The existing memory area item is edited by selecting the appropriate item in the list
and by clicking Edit or double-clicking the memory area item. The selected items
are displayed in the Memory Area Configuration Editor with the existing definitions
(see Fig. 16.17.-8). In this dialog, the data type, coding, start address, length, access
type, block format, time stamp and split destination are defined.
208
STA_Advanced3
Fig. 16.17.-8 Editing the existing memory area item
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 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.
209
Values:
1 - 8 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
The word address of the first word’s memory area. Value range: 0 - 32767.
Length
Number of words in the memory area. Value range: 0 - 32767.
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
States if the spontaneous command messages from the station use the basic format
of the protocol, or if an additional address field is utilized. 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
States whether the time tagged information is included in spontaneous commands
from the station. Values:
0 = No Time Stamp
1 = Time Stamp
210
Message Split Destination List

Defines the applications that will receive the message. Receiving applications can
only be defined if message split is activated (SP > 0).
211
17. NETCONF Tool

This chapter describes the preconfiguration tool, NETCONF. The tool is used for the
preconfiguration of DCP-NET. The tool runs under the DOS operating system and
performs the same tasks as the NET PRECONFIGURATION tool.
17.1. Requirements
The NETCONF program requires a PC computer running under the MS-DOS
operating system with 286 processor or later, and at least 512 kB memory. Running
NETCONF requires at least 1 Mb free disk or diskette memory.
17.2. Installation
To install the NETCONF program:
1 Create a subdirectory for NETCONF.
If you want to install NETCONF on the C: drive in the NETCONF directory
enter the following command:
MD C:\NETCONF
If you are using the Windows operating system:
1. In the Windows Explorer (Start - Programs - Windows Explorer) select drive C:.
2. In the menu bar choose File, point New and click Folder.
3. Enter the name NETCONF to the created folder.
2 Copy the NETCONF program from the MicroSCADA installation CD to
the newly created directory. The NETCONF program can be found in
directory \Frontend\netconf on the CD.
If you have the installation CD in drive E: and want to copy the program to
C:\NETCONF, enter the following command:
COPY E:\FRONTEND\NETCONF\NETCONF.EXE C:\NETCONF
In the Windows Explorer:
1. Double-click the CD drive.
2. Double-click the folder FRONTEND.
3. Double-click the folder NETCONF.
4. Select the file NETCONF.EXE and press Ctrl+C on the keyboard.
5. Select the file NETCONF in the drive C: and press Ctrl+V on the keyboard.
17.3. NETCONF tool basics
Use
The NETCONF tool is applied for viewing, adding, modifying, copying and
documenting the preconfiguration parameters stored in the communication
programs. It can also be used for verifying the consistency of communication
programs.
187
The NETCONF tool runs under the DOS operating system. It is therefore convenient
to use NETCONF for the preconfiguration of stand-alone communication units.
There is also a tool for preconfiguration handling during the MicroSCADA
operation. The tool performs the same tasks as NETCONF and is to be preferred
when internal frontends are preconfigured. For information on this tool, see chapter
15.
The preconfiguration tools should only be used by the system managers.
Files
The NETCONF tool can recognise and handle two types of files:
• Communication program files including configuration data.
• Journal files, which contain only the preconfiguration data, not the entire
communication program. These files are created by NETCONF or the NET
PRECONFIGURATION tool and can be used exclusively by NETCONF and the
NET PRECONFIGURATION tool. The journal files cannot be used in a running
communication unit.
Buffers
The NETCONF tool can use two buffers:
• A base buffer containing the configuration data to be modified. This data is called
base data.
• If needed, an extra buffer which can contain configuration data to be viewed or
copied. This data is called extra data.
The base buffer must always be loaded with a communication program. The extra
buffer can contain a communication program or a journal file.
Menu selections
The NETCONF program is used through a number of menus: one main menu which
goes horizontally on the screen and a number of sub-menus in the shape of drop-
down menus. The drop-down menus in turn can contain other sub-menus. A menu
selection is indicated by a highlighted cursor, which is moved by the arrow keys,
Home and End, see below. The Esc key performs a return to the previous level of
menus.
In order to select a menu option:
1. Move the highlighted cursor to the menu item.
2. Press Enter.
188
Fig. 17.3.-1 The NETCONF start-up screen
Keyboard keys
The keyboard keys are used in the following way:
Enter Execution. The key executes the option selected by the
highlighted cursor.
Esc Return. The key exits the current menu and returns to the
previous menu, i.e. the menu one step upwards in the menu
hierarchy. In the main menu this key exits the NETCONF
program without storing the made modifications.
Up Arrow Up, down. In the drop-down menus, the keys move the Down
Arrow highlighted cursor one step up and down respectively.
Left Arrow Left, right. In the main menu, these keys move the Right Arrow
highlighted cursor to the left and to the right respectively.
Home First option. The key moves the highlighted cursor to the first
option in the menu.
End Last option. The key moves the highlighted cursor to the last
option in the menu.
F1 Help. The key displays a help text. If no help text is available, an
error message will be shown.
F2 , space Direct selection. The key enables a direct selection of another
device of the same type. If you, for example, want to edit line 9
while you are editing line 3, press F2, type 9 and press Enter.
Return to line 3 by pressing F2, 3 and Enter.
F3, PgDn Next item. The key browses to the next object of the same type.
F4, PgUp Previous item. The key browses to the previous object of the
same type.
F5, Tab This key works only for stations of type Allen-Bradley. The key
displays a window containing the configuration data of the
memory rung of the actual station, starting from memory rung
number 1.
189
F9 Options. This key displays a window with a number of options,

e.g. the display format of the attribute data. See “Options” on
page 191on the next page.
F10, Esc Return to the previous level.
17.4. Using NETCONF Tool
Start-up
To start the NETCONF program:
1. Move to the NETCONF directory.
If NETCONF was installed in the C: drive in the NETCONF directory, enter the
following commands:
C:
CD \NETCONF
2. Start the NETCONF program by entering:
NETCONF [-M] [file]
Start-up from the Windows Explorer:
1. In the C: drive double-click the NETCONF folder.
2. Double-click the file NETCONF.EXE.
By default, the program uses the colour mode. Including the optional argument -M
means that the program will be run in the monochrome mode. The mode can also be
selected during the program execution, see “Options” on page 191 on the next page.
The optional argument 'file' means the name of the file to be loaded to the base
buffer. The file must be a communication program file. The file can also be loaded
after the program has been started.
The appearance of the screen is shown on the previous page (see Fig. 17.3.-1).
Before you load a file to the NETCONF tool, make sure you have a
backup copy of the file.
Loading a base buffer

If no file name was given at the start-up, a file must now be loaded into the base
buffer. Load the communication program to be configured, viewed, copied,
documented or verified in the following way:
1. Select "Load".
2. Select "Base NET-Data (and File)" and enter the name of the communication
program to be loaded into the base buffer. The file name should include the path,
if the file is located in another directory than the current one.
While NETCONF loads the file, it verifies the consistency of the file.
Checking input file ...

Loading main buffer from file ....
190
When the file has been loaded successfully, the following message is displayed:
*** File read OK ***

[8.4.2/X8]
[DCP-CARD]
OK
If the loading did not succeed, one of the following messages are displayed:
*** Modules Missing***
Frame Checksum ERROR
or
Can't access input file: ....
The last error message indicates that the file cannot be found. Check that you have
typed the name of the file correctly.
Now you can continue in any of the following ways:
• By modifying the preconfiguration in the base buffer and storing the new
configuration.
• By loading the extra buffer with a communication program or a journal file. This
enables you to easily copy the preconfiguration from another file.
• By viewing the configurations in the base and extra buffers.
• By documenting the base buffer.
Loading an extra buffer

In order to load a file into the extra buffer:
1. Select "Extra Data from NET-File" in order to load a communication program,
or select "Extra Data from Journal-File" in order to load a journal file.
2. Enter the name of the file, including the path if the file is located in another
directory then the current one.
Options
The appearance and function of the NETCONF program itself can be changed in
the following way:
1. Select "Options" in the main menu, or press F9 (it can be pressed any time).
The following options can be selected:
Toggle Screen Colours This item toggles between colour and monochrome
display mode.
Disable Field Check Toggles the field check state.
Enable Field Check When the field check is on, the cursor cannot be moved up
and down with the arrow keys, unless the Enter key has
been pressed
Display Format The attribute values can be displayed and entered in three
different ways:
Numeric 5-Dig: The values are displayed with five digits
with leading zeroes.
191
Numeric: Values are displayed numerically without

leading zeroes.
Text-format: Values are displayed as texts where
applicable.
Disable This NET Conf. Normally, it is possible to change the attributes of the
current NET. By means of this option, changes can be
disabled.
Enable This NET Conf. Enables attribute changes in the current NET
The Options menu also provides means for using DOS without exiting NETCONF,
see “Select "In Journal File" and enter the name of the file.” on page 195 on the last
page of this chapter.
Viewing the configuration

To view the configuration:
1. Select "Show" in the main menu.
2. Select "Summary" to get a summary of both the base data and the extra data.
or
3. Select "Base Data" to get a detailed description of the configuration in the main
buffer.
or
4. Select "Extra Data" to get a detailed description of the configuration in the extra
buffer.
The detailed descriptions have the same appearance and menu structure as the
"Modify" option, except that no changes can be performed. For more information on
the "Modify" option, see below.
Modifying the configuration

To modify the configuration:
1. Select "Modify" in the main menu.
2. Select the item, which you are going to configure:
"This node" For modifying the attributes of the current NET
"Lines" For adding and modifying the lines
"Stations" For adding and modifying stations (STA objects)
"Printers" For adding and modifying printers (PRI objects)
"Applications" For defining applications to NET
"External Nodes" For defining other NETs, base systems and NET object
"Memory Rungs" For modifying the memory rungs of stations of ANSI type
"Digitizers" and "Monitors" are not used in the current version of MicroSCADA.
When a new device is added, a "Device Type" is requested. NETCONF uses the
following names and code numbers for the device types:
1 APL Application
2 NOD Node: a communication unit or a base system
192
3 STA Stations on ANSI lines

4 RTU S.P.I.D.E.R. RTUs
5 SIN Stations of type SINDAC using the ADLP80 protocol
6 PCL Stations of type P214
7 SID Stations of type SINDAC using the ADLP180 protocol
8 PAC Stations of type PAC-5
9 SAT Stations of type SATTCON using the COMLI protocol
11 PRI Printer
20 LCU Stations of type Load Control Unit
21 SPA SPACOM
22 SPI S.P.I.D.E.R./RP 570
To modify an attribute line:
1. Move the highlighted cursor to the line and press Enter.
2. Type a new value for the selected attribute and press Enter.
The attributes of the own NET ("This Node") cannot be changed, if

the option "Disable this NET Conf." has been selected.
To delete an object:
1. Set the "Device type" to "not" or 0.
The line protocol can be given by a code number or a text abbreviation. The
following code numbers and abbreviations are used:
1 XF ANSI X3.28 Full Duplex or MicroPROTOCOL
2 XH ANSI X3.28 Half Duplex
3 RM Common RAM
4 AS ASCII
7 SR RP 570
8 AD ADLP80
9 PR P214
10 AL ADLP180
11 CL COMLI
12 LC LCU500
13 AM ALDP180 Master
14 SP SPA
15 AG ASCII General
16 RP RP 570 Slave
193
Copying the configuration

1. Select "Copy" in the main menu.
The configuration of the extra buffer can be copied to the configuration of the base
buffer and vice versa. In order to copy the configuration of the extra buffer to the
base buffer:
2. Select "Ext. -> Base".
3. Confirm the copy operation by selecting "OK".
In order to copy the data from the extra buffer to the base buffer:
4. Select "Base -> Ext.".
5. Confirm by pressing Enter.
The configuration is always copied completely. Individual devices cannot be
copied, neither inside a buffer nor between the buffers.
Documenting the configuration

The NETCONF tool can be used to create a text file containing the
preconfiguration in a text format. To do this:
1. Select "Save" in the main menu.
2. Select "In Document File".
3. Select the format: of the document "Brief Doc.", "Normal Doc." or "Full Doc.".
The "brief" document gives an overview of the configuration, including line
protocols and connected devices, but no attributes. The "normal" document lists all
devices and lines including their attributes. "Full" means that both types of
documents are produced.
4. Enter file name. Recommendation: give the file name the extension .DOC to
distinguish it from the program and journal files.
Saving the configuration

The configuration can be saved in the communication program, whereby the former
configuration is lost, or it can be saved as a journal file. If the configuration will not
be used directly in a communication program, a journal file is recommended because
the journal files are smaller than the communication files.
To save the configuration:
1. Select "Save" in the main menu.
In order to save the preconfiguration in the communication program which must
have been loaded as base buffer:
2. Select "In NET file" and enter the name of the file.
Recommendation: Give the communication program such a name

that the node number appears from it, e.g., NETnn.84, where 'nn' is
the node number.
194
In order to store the preconfiguration as a journal file:

1. Select "In Journal File" and enter the name of the file.
Recommendation: Use the extension .JOU for journal files.
Using DOS gateway

This option is found in the "Options" menu. It enables the use of DOS commands
without exiting the NETCONF program:
1. Select "DOS Gateway".
2. Enter the DOS commands.
In order to return to NETCONF:
3. EXIT and press Enter.
195
18. NET Tool

This chapter describes the online preconfiguration tool, which is used for the
preconfiguration of the DCP-NET. The tool is located on the Configuration page of
the Tool Manager System .
Fig. 18.-1 Starting the NET configuration tool
18.1. NET Tool basics
Use
The NET tool is applied for viewing, adding, modifying, copying and documenting
the preconfiguration parameters stored in the communication programs. It can also
be used for verifying the consistency of communication programs.
The preconfiguration tool should be used by the system managers only.
Files
The NET preconfiguration tool can recognise and handle two types of files:
• Communication program files including configuration data.
• Journal files, which contain only the preconfiguration data, not the entire
communication program. These files are created by the NET configuraton tool
and can be used by this tool exclusively. The journal files cannot be used in a
running communication unit.
Buffers
The NET preconfiguration tool uses three buffers. Each of these buffers can be
loaded with a communication program or a journal file.
197
Function keys
Start the NET preconfiguration tool by clicking the NET PRECONFIGURATION
button on the NET CONFIGURATION page.
Fig. 18.1.-1 The NET CONFIGURATION page

The NET PRECONFIGURATION tool provides a menu of function keys at the
bottom of the screen (see Fig. 18.1.-2).
LOAD Loads the program and journal files into the buffers and
stores them.
SAVE Allows the user to save the files.
VIEW Allows the user to view the configuration of the buffers.
The configurations can be displayed in brief or full
format.
MODIFY Allows the user to modify the preconfiguration of the
selected buffers.
198
COPY Allows the user to copy the complete preconfiguration

from one buffer to another or individual devices of the
preconfiguration within the same buffer or from one
buffer to another.
MISCELLANEOUS Allows the user to change the display mode of the
preconfiguration data, include or exclude attribute names
when displaying configuration data and check the
configuration.
Fig. 18.1.-2 The NET PRECONFIGURATION tool
18.2. Using the NET PRECONFIGURATION Tool
Startup
To open the NET PRECONFIGURATION tool:
1. The NET PRECONFIGURATION tool is opened by clicking the NET icon
located on the System Configuration page of the Tool Manager (see Fig. 18.-1).
2. Click the NET PRECONFIGURATION button (see Fig. 18.1.-1).
199
The window gets the appearance shown on the previous page (see Fig. 18.1.-2).
Before you load a file to the NET PRECONFIGURATION tool,

make sure you have a backup copy of the file.
Loading buffers
Load the communication programs or the journal files to be configured, viewed,
copied, documented or verified in the following way:
1. Click LOAD SAVE.
2. If you have loaded one or more files into the buffers, select the buffer to load.
The first file loaded is always loaded into buffer 1. A window appears on the
screen.
3. Enter the name of the file to be loaded. The tool assumes that the file is located
in the SYS_ directory. Change the path if the file is in any other directory.
While NET PRECONFIGURATION loads the file, it verifies the consistency of
the file. If the loading did not succeed, an error message is displayed. For
example:
*** Modules Missing***
Frame Checksum ERROR
Can't access input file: ....
The last error message indicates that the file cannot be found. Check that you have
typed the name of the file correctly.
Now you can continue in any of the following ways:
• By loading other buffers with a communication program or a journal file.
• By viewing the configurations in the buffers.
• By copying the preconfigurations from one buffer to another.
• By modifying the preconfiguration in the buffers. The configuration of individual
devices can be copied.
• By storing the new configuration.
• By documenting the configurations in the buffers.
Display mode
The attribute values can be displayed and entered in two ways:
• In numeric format. This is the format used in the attribute descriptions in the
System Objects manual.
• In text format, which means that the attribute values are displayed as short
descriptive texts where applicable.
In order to change the view mode of the attribute values:
1. Click MISCELLANEOUS
2. Click CHANGE VIEW MODE.
If desired, the two-letter attribute names can be included in the list of the
configuration data. In order to include or exclude the attribute names:
3. Click MISCELLANEOUS.
200
4. Click ATTRIBUTE NAMES.
Viewing the configuration

To view the configuration:
1. Click VIEW.
2. Click SUMMARY to get a summary of the configuration in two buffers.
or
Click BUFFER1, BUFFER2 or BUFFER3 to get a detailed description of the
configuration in respective buffers.
The detailed descriptions have the same appearance as in the MODIFY option (see
below), except that no changes can be performed.
Modifying the configuration

To modify the configuration:
1. Click MODIFY.
2. Select the buffer, if several buffers have been loaded.
3. Click in the window with the text: PRESS HERE TO SELECT DEVICE TYPE!
4. Select the device type:
THIS NODE For modifying the attributes of the current DCP-NET
LINES For adding and modifying the lines
STATION For adding and modifying stations (STA objects)
PRINTER For adding and modifying printers (PRI objects)
APPLICATION For defining applications to NET
EXTERNAL NODE For defining other NETs and base systems (NET objects)
MEMORY RUNGS For modifying the memory rungs of stations of ANSI type
The device type can be changed any time by clicking the text PRESS HERE TO
SELECT DEVICE TYPE!
201
The tool uses the following names and numbers for the device types:
1 APL = Application
2 NOD = Node: communication unit or base system
3 STA = Stations on ANSI lines
4 RTU = S.P.I.D.E.R. RTUs
5 SIN = Stations of type SINDAC using the ADLP80 protocol
6 PCL = Stations of type P214
7 SID = Stations of type SINDAC using the ADLP180 protocol
8 PAC = Stations of type PAC-5
9 SAT = Stations of type SATTCON using the COMLI protocol
11 PRI = Printer
20 LCU = Stations of type Load Control Unit
21 SPA = SPACOM
22 SPI = S.P.I.D.E.R./RP 570
In order to create a new device of the selected type:
1. Browse to a free device number by clicking on the arrow keys in the upper part
of the window.
2. Click CREATE.
The attributes of the new object get the default values.
In order to modify an attribute:
1. Click the attribute field.
A window appears with a list of possible values.
2. Enter a new value or select one from the list.
In order to delete an object:
Browse to the object and click DELETE.
Copying the configuration

The total configuration of one buffer can be copied to another buffer, or individual
devices can be copied between the buffers or within the same buffer.
In order to copy the complete configuration from one buffer to the other:
1. Click COPY.
2. Enter the number of the source buffer and the number of the destination buffer.
3. Click EVERYTHING, CLEARING DEST. BUFFER FIRST. This option clears
the destination buffer before copying the configuration to it.
or
Click EVERYTHING; MERGE. This option adds the configuration
definitions from the source buffer to the destination buffer. If a device is defined
in the source and destination buffer, the definition in the destination buffer will
be changed.
4. Click COPY INFO.
202
In order to copy individual devices:

1. Click COPY.
2. Enter the number of the source buffer and the number of the destination buffer.
3. Select the device type by clicking on the type.
4. Enter the number of the device to be copied.
5. Enter the destination device number.
6. Click COPY INFO.
Documenting the configuration

The NET PRECONFIGURATION tool can be used to create an ASCII file
containing the preconfiguration in a text format. To document the configuration:
1. Click LOAD SAVE.
2. Click SAVE DOCUMENT FILE.
3. Select the buffer to be documented.
4. Enter the file name.
Recommendation: give the file name the extension .DOC to

distinguish it from the program and journal files.
5. Select the documentation format: “Brief”, “normal” or “full” document by

clicking BRIEF, NORMAL or FULL.
The “brief” document gives an overview of the configuration, including line
protocols and connected devices, but no attributes. The “normal” document lists
all the devices and lines including their attributes. “Full” means that both types
of document are produced.
6. Click CREATE DOCUMENT FILE.
Saving the configuration

The configuration can be saved in the communication program or it can be saved as
a journal file. If the configuration will not be used directly in a communication
program, a journal file is recommended because the journal files are smaller than the
communication files.
In order to save the preconfiguration in a communication program:
1. Click LOAD SAVE.
2. Click SAVE IN NET FILE and enter the name of the file.
Recommendation: Give the communication program such a name

that the node number appears from it, for example, NETnn.84,
where 'nn' is the node number.
203
In order to save the preconfiguration as a journal file:

1. Click LOAD SAVE.
2. Click SAVE IN JOURNAL FILE and enter the name of the file.
Recommendation: Use the extension .JOU for journal files.
204
19. REx Configuration Tool

The REx Configuration tool is used for making the necessary system object
definitions to the PC-NET for the REx type of protection relay units. The definitions
are mostly involving LON/SPA communication and parameters related to command
handling of the protection relay. Using REx configuration tool is an alternative for
the default PC-NET configuration stored into PC_NET.COM file. REx
configuration tool produces a file with .cfg extension containing the STA object
definitions. To utilise the configuration file, the SCIL command line program
proc_rex.scl. must be run.
Although the REx Configuration tool still exists in the Tool

Manager, it is recommended to use the System Configuration Tool
instead.
19.1. Using REx Configuration Tool

The picture below (see Fig. 19.1.-1) shows the REx Configuration Tool. It is
composed of a menu bar at the top, an area for selecting Device Number and two
pages. The pages are named Device Attributes and SPA Points.
Fig. 19.1.-1 The REx Configuration Tool

The menu bar consists of the File, Edit, Device and Help menus. The File menu
contains options for file handling and exiting the tool. The Edit menu contains
options for copying and moving. The Device menu contains options for adding,
renaming and deleting devices. In the Help menu you can choose the About dialog,
which displays information about the tool.
205
Operation
The REx Configuration tool is used according to the same principles as other
Windows based applications. The tool is used for off-line REX station configuration
to the PC-NET.
Opening and closing

The REx Configuration Tool is opened by clicking the REx Config icon on the
System Configuration page of the Tool Manager.
To close the tool, choose Exit from the File menu.
Opening files
The configurations are saved in a configuration file.
You can either open a file that already exits or create a new one. To open a file:
1. Choose Open from the File menu. The file chooser appears on the screen.
2. Choose a folder and a file. The default extension for the file is .cfg.
3. Click OK. The configuration file is loaded. If you have not saved changes to the
previous file, you can do it at this point.
Saving files
To save a file choose Save or Save As from the File menu. The Save option saves
the file with the current name.
The Save As saves the file with a name the user specifies. The default file extension
is .cfg. The default folder and path is \sc\sys\active\sys_. If the specified path does
not exist, a notification will appear on the screen. If the folder already contains a file
with that name, you will be asked whether you want to replace the existing file.
Copying
You can copy devices, characters and SPA points. To copy:
1. Select the part you want to copy.
2. Choose Copy from the Edit menu. The part is copied to the clipboard.
3. Place the cursor at the position where you want to insert the copied part.
4. Choose Paste from the Edit menu. A new SPA Point is added to the end of the
SPA Points list.
Moving
You can move devices, characters and SPA points. To move:
1. Select the part you want to move.
2. Choose Cut from the Edit menu. The text is moved to the clipboard.
3. Place the cursor at the position where you want to insert the part.
4. Choose Paste from the Edit menu. A new SPA Point is added to the end of the
SPA Points list.
206
Adding devices
To add a device:
1. Choose Add from the Devices menu.
2. Type the name of the device in the dialog box that appears on the screen.
3. Click OK. If the device number exists, a notification appears on the screen.
Click Yes, if you want to replace the previous device with that number.
Otherwise click Cancel.
Renaming devices
To change the number of the device:
1. Select the device.
2. Choose Rename from the Device menu and type the new number. Click OK.
Deleting Devices
To delete a device:
1. Select the device.
2. Choose Delete from the Device menu and confirm the deletion by clicking Yes.
19.2. Defining the device
Device attributes
The device attributes are defined in the Define Attributes page. The following
attributes can be defined (for more information on the attributes, see the System
Objects manual):
Allocation AL
In Use IU
Message Identification MI
This attribute is automatically calculated when a new
device is added. The automatic calculation is based on the
formula (1000 + Device Number).
Node Number NN
REx Line Number RX
Running Mode RM
Subnet Number SN
Unit Number UN
Unit Type UT
SPA points
The binary output objects of the REX stations are defined in NET as SPA points.
REX commands and SYS process objects are tied together using the SPA point
definition. The main purpose of this definition is to create a cross-reference between
the SPA items and the SYS process object addresses. The purpose of this definition
is also to tell NET how to convert a command from SYS to the corresponding SPA
command.
207
The SPA points for REx devices are defined in the SPA Points page (see Fig. 19.2.-
1) . One device number can consist several SPA points. To add a new SPA point,
click Add. The point is appended to the end of the list. Enter the following
information:
Type 10 (transparent-SPA command def.)
Channel 1 A value between 0...999
Channel 2 A value between 0...999
Data Category The available values are I, O, S, V, M, C, F, T, D, F, T, D,
L, B
Data 1 A value between 1 ... 999999
Data 2 A value between 1 ... 999999
Data Format The available values are bits, hexadecimal, real and
longinteger
Object Address The base system process object address that is connected
to this SPA point
For more information on the SPA point definition, see the corresponding manual for
the relay.
To modify an existing SPA point, double-click its row in the list or select the row
and click Edit. To delete a selected SPA point, click Delete.
Fig. 19.2.-1 The SPA Points page in the REx Configuration Tool
Interpreting the definitions

An interpreter is used to utilise the definitions. The interpreter is a SCIL command
line program, which takes the configuration file name and the default net number as
input parameter. The output of the interpreter is a collection of #SET commands,
which are automatically executed.
Argument 1 The configuration file name
Argument 2 The default net number
208
Example:
@rex_test = do(read_text("sys_tool/proc_rex.scl"),"sys_/example.cfg",1)
The interpreter is located in the folder that is referred with logical name sys_tool.
The file name is proc_rex.scl.
An example of the result of the configuration file interpretation.
#SET NET1:SRX1=1
#SET STA1:SAL=1
#SET STA1:SNN=1
#SET STA1:SRM=7
#SET STA1:SSN=1
#SET STA1:SUT=1
#SET STA1:SUN=1
#SET STA1:SMI=1001
#SET STA1:SSP1=(10,12,12,"I",221,221,4,1)
#SET STA2:SSP2=(10,12,12,"I",241,241,4,2)
#SET STA2:SSP3=(10,12,12,"I",261,261,4,3)
#SET STA2:SSP4=(10,12,12,"I",281,281,4,4)
#SET STA2:SSP5=(10,12,12,"I",301,301,4,5)
#SET STA2:SSP2=(10,12,12,"I",321,321,4,6)
#SET STA2:SSP2=(10,12,12,"I",341,441,4,7)
#SET STA2:SSP2=(10,12,12,"I",361,361,4,8)
#SET NET1:SRX2=1
#SET STA2:SAL=1
#SET STA2:SNN=3
#SET STA2:SRM=7
#SET STA2:SSN=1
#SET STA2:SUT=1
#SET STA2:SUN=2
#SET STA2:SMI=1002
#SET STA1:SIU=1
#SET STA2:SIU=1
#SET NET1:SIU1=1
209
20. LMK Configuration Tool

We recommend that you use the System Configuration tool instead
of the LMK Configuration tool.
The LMK Configuration tool is used for making the necessary on-line system object
definitions to the PC-NET for LMK stations.
20.1. Using LMK Configuration Tool

The picture below (see Fig. 20.1.-1) shows the LMK Configuration Tool. It is
composed of a menu bar at the top, an area for selecting the Device Number and
three pages. The pages are named Device Attributes, Diagnostic Counters and LON
Points.
The menu bar consists of the Configuration, Edit, Device, Net and Help menus. The
Configuration menu contains options for fetching the attributes of defined LMK
stations and exiting the tool. The Edit menu contains options for copying and
moving. The Device menu contains options for fetching, sending messages, adding,
renaming and deleting devices. The Net menu contains an option for defining NET
Properties. In the Help menu you can choose the About dialog, which displays
information about the tool.
LMK_config
Fig. 20.1.-1 The LMK Configuration Tool
211
Operation
The LMK Configuration tool is used according to the same principles as other
Windows based applications. The tool is used for on-line configuring of LMK
station, e.g. LSG devices connected to LON and LONWORKS devices other than
REX type stations.
Opening and closing

The LMK Configuration Tool is opened by clicking the LMK Config icon located
on the System Configuration page of the Tool Manager.
To close the tool, choose Exit from the Configuration menu.
Fetching
Fetching reads the LMK stations from the PC-NET. The stations that were found are
listed in ascending order in a device list. If no LMK stations are found, a notification
will appear on the screen.
Copying
You can copy devices, characters and LON points. To copy:
1. Select the text you want to copy.
2. Choose Copy from the Edit menu. The text is copied to the clipboard.
3. Place the cursor at the position where you want to insert the copied part.
4. Choose Paste from the Edit menu. If you paste a station, you should rename it.
This is because every station should have a different number. If you paste a
LON Point, you should edit the NV Index. This is because every LON Point
should have its own NV index. A new LON Point is added to the end of the
LON Points list.
Moving
You can move devices, characters and LON points. To move:
1. Select the text you want to move.
2. Choose Cut from the Edit menu. The text is moved to the clipboard.
3. Place the cursor at the position where you want to insert the part.
4. Choose Paste from the Edit menu. A new LON Point is added to the end of the
LON Points list.
Cutting the Device or LON Point from the list copies its contents to clipboard. At
the same time it is deleted in the PC-NET. If the cut or deleted LON Point is not the
last one in the list, all the points after that are collapsed one index.
Fetching devices
Fetching reads the latest information for a selected device from the NET. To fetch,
select the device and choose Fetch from the Device menu. The information appears
on screen.
212
Adding devices
To add devices:
1. Choose Add from the Device menu.
2. Type the number of the device in the dialog box that appears on the screen.
3. Click OK. If the device number exists, a notification will appear on the screen.
Click Yes, if you want to replace the previous device with that number.
Otherwise click Cancel.
When a device is added into configuration, it is expected that the corresponding
station object is already defined in the base system. A notification will appear on the
screen, if it is not defined.
Renaming devices
You can change the number of the device by choosing Rename from the Device
menu and typing the new number. Then click OK.
Deleting devices
You can delete a device by choosing Delete from the Device menu and confirming
the deletion by clicking Yes.
Sending messages
Using the LMK Configuration Tool you can send a LONTALK message to a
selected device. To send a message:
1. Choose Send Message from the Device menu.
2. Type the message as hex string in the dialog box that appears on the screen.
3. Click Send. The response message is displayed to the received message field. If
an error occurs, a notification will appear on the screen.
4. Click Close.
NET properties
By using the NET properties you can specify the default NET number. It is used
when a line is changed from on-state to off-state. The default NET link number is
used when LON stations are added to the NET. When a LON station is added to a
different link, the default link number should be changed before adding.
To define the NET properties:
1. Choose Properties from the NET menu.
2. Type the Net Number and Default Net Link Number in the dialog box that
appears on the screen.
3. Click OK. If an invalid value for NET Properties is given, a notification will
appear on the screen. The values will be accepted, if they do not generate a
SCIL error code.
It is assumed that when the NET number is changed, the base system contains the
definition for the node object with a specified number. It is also assumed that when
the default link number is changed, the base system includes the definition for the
link object with the specified number.
213
20.1.1. Defining the device

When a station is selected from the Device list, the latest information for that device
is read from the PC- NET.
Defining the device attributes

The device attributes can be defined by using the Define Attributes page in the
LMK Configuration Tool. These attributes are specific to every device number. The
following attributes can be defined (for more information on the attributes, see the
System Objects manual):
In Use IU
Allocation Enabled AL
Allocation Application AS
Consistency Check Time CT
Diagnostic Interval DI
Link Number LI
When changing the link number, the link line is first
stopped and then started during the set operation
Message Identification MI
The Message Identification is automatically
calculated, when a new device is added.
Message System MS
Node Number NN
Object Status OS
Reply Timeout RT
Subnet Number SN
Unit Type UT
General Interrogation GI
Defining diagnostic counters

Diagnostic Counters are used to collect information concerning different counters
for the selected device number. The current diagnostic counter value is displayed
under the label Current Value for the specified counter.
The current values for the diagnostic counters can be stored to a data log. To store,
click Store Data Log. The stored diagnostic counter values are displayed under the
label Stored Value for the specified counter. Reset Counters operation resets the
current diagnostic counter values. To remove the stored diagnostic counter values
from data log, click Remove Data Log. When a data log is stored for the current
device number, the values from the data log are displayed when you open the
Diagnostic Counters page.
When the Diagnostic Counters page is open, the LMK Configuration Tool reads the
counters from the NET after every 2 second.
214
Defining LON points

LON Points for devices can be defined by using the LON Points page. One device
number can consist of none, one or multiple LON points. When a new
LONWORKS point is added, it is appended to the end of the list. The valid LON
Point definitions are:
• Digital input
• Analog input
• Digital output
• Analog output
• Struct input
When the selected LON Point definition does not have some of the basic attributes
(NV Index, LON Base Type, SD String, SNVT Type, Process Object Address or
Deadband), it is displayed as being dimmed in the LON Point definitions dialog.
To modify an existing LON point, double-click its row in the list or select the row
and click Edit. To delete a selected LON point, click Delete.
Fig. 20.1.1.-1 The LON Points page in the LMK Configuration tool
Initialization file
The initialization file of the LMK Configuration tools uses the Windows
initialization file format. The file is read during the starting procedure of the tool. If
an attribute definition does not exist, the default values will be used (Default Net
Number is 1, Default Net Link Number is 1). Below is an example of the
initialization file:
[LMKStation]
Default_Net_Number=3
Default_Net_Link_Number=2
The definition for attributes is the following:
215
Default_Net_Number
Specifies the default net number used when adding or deleting LMK Stations in
net.
E.g. #SET NET3:SLM1=2
Default_Net_Link_Number
Specifies the default net link number used when adding or deleting LMK Stations
to link object.
E.g. #SET NET3:SLM1=2
216
21. Index
Symbols
#CREATE ................................................................................................. 17
#SET ......................................................................................................... 30
A
AA ............................................................................................................ 41
AC ........................................................................................................... 165
ACE ........................................................................................................ 165
ACE AT S Register ................................................................................ 165
ACP .......................................................................................................... 51
AD ............................................................................................................ 92
AE ........................................................................................................... 111
AL ....................................................................................... 84, 90, 207, 214
Alarm ........................................................................................................ 12
Allen-Bradley PLC ................................................................................... 87
Allocation ............................................................................................... 207
Analog Events ........................................................................................ 111
Analog input ........................................................................................... 215
Analog output ......................................................................................... 215
ANALOG_SWITCH_STATE_CLOSED ................................................ 20
ANALOG_SWITCH_STATE_MIDDLE ................................................ 20
ANALOG_SWITCH_STATE_OPEN ..................................................... 20
ANSI X3.28 ............................................................................................ 162
ANSI X3.28 protocol ................................................................................ 89
ANSI X3.28/A-B protocol ........................................................................ 87
AP ..................................................................................................... 43, 133
APL ............................................................................................... 43, 53, 59
APL object .................................................................................... 17, 88, 90
APL_EVENT ......................................................................................... 111
APLn
BMO ................................................................................................... 77
BPR ..................................................................................................... 80
Application ................................................................................................. 9
Application Suspension Time ................................................................. 161
Apply button ........................................................................................... 204
AS ....................................................................... 37, 43, 44, 84, 88, 90, 133
AT ............................................................................................................. 92
Attribute group ....................................................................................... 179
Attribute Tree ......................................................................................... 179
Auto-dial ................................................................................................. 164
AW ......................................................................................................... 100
B
Base system ................................................................................................ 9
Base system configuration .................................................................. 41, 89
217
Base system objects .................................................................................. 17

Baud Rate ................................................................................................. 38
BF ............................................................................................................. 92
BR .......................................................................................... 38, 70, 84, 90
BREAK TIME ....................................................................................... 153
Buffer pool ............................................................................................... 60
C
CA ........................................................................................ 40, 41, 86, 169
Cancel button ......................................................................................... 204
CCR2 responses ..................................................................................... 165
CF ....................................................................................................... 40, 41
CL ............................................................................................... 41, 80, 165
CLOCK .............................................................................................. 40, 86
Clock address ........................................................................................... 40
Clock read frequency ............................................................................... 40
Clock Synchronisation ........................................................................... 167
Clock Type ............................................................................................... 40
Clock, external ......................................................................................... 86
CMOD .............................................................................................. 37, 147
CN .......................................................................................................... 165
CO ............................................................................................................ 92
COM ......................................................................................................... 38
COM Port for ASCII General .................................................................. 39
COMAG ............................................................................................. 39, 86
Common RAM ......................................................................................... 58
Communicating applications .................................................................... 45
Communicating NETs
Example .............................................................................................. 71
Communication board .............................................................................. 58
Communication front-end ........................................................................ 65
Communication frontend ......................................................................... 10
Communication loop .............................................................................. 151
System architecture .......................................................................... 151
Communication Port ................................................................................ 38
Communication system .............................................................................. 9
Communication System Objects ........................................................ 27, 29
Communication unit configuration .............................................. 63, 88, 89
CONFIG. TIME ..................................................................................... 153
Configuration software ............................................................................. 14
Connection ............................................................................................. 165
Connection Time .................................................................................... 165
Connection Time Limited ...................................................................... 165
Copy/Paste .............................................................................................. 182
CPNOD ............................................................................................ 38, 147
CSRC ........................................................................................................ 37
CT ........................................................................................................... 165
218
Cut .......................................................................................................... 182

D
Data files
Configuration ...................................................................................... 35
File format .......................................................................................... 35
DC ..................................................................................................... 82, 169
DCD ........................................................................................................ 162
DCP/MUXi ............................................................................................... 58
DCP-NET ........................................................................................... 21, 28
DCP-NETs .......................................................................................... 14, 57
DD .......................................................................................................... 165
DE ................................................................................................. 41, 90, 91
Debug support ........................................................................................ 171
Default configuration .............................................................................. 176
Default values ......................................................................................... 179
DELETE ................................................................................................... 18
Delete ...................................................................................................... 182
Device ....................................................................................................... 42
Device Connection ................................................................................. 169
Device Type ............................................................................................ 169
DI ........................................................................................................ 36, 91
Diagnostic Command Interval .................................................................. 36
Dial-up .................................................................................................... 162
Digital input ............................................................................................ 215
Digital output .......................................................................................... 215
DM ............................................................................................................ 41
DN ............................................................................................................ 41
DS ....................................................................................................... 41, 60
DST ................................................................................................... 36, 147
DT ......................................................................................... 77, 82, 92, 169
DTR ........................................................................................................ 144
DTU .......................................................................................................... 87
DU ............................................................................................................ 42
E
ED ........................................................................................................... 168
EM ............................................................................................ 44, 109, 168
Embedded Response ................................................................................. 39
EN ......................................................................... 39, 61, 63, 65, 70, 89, 90
ENQ Limit ................................................................................................ 39
EP ........................................................................................................... 109
ER ........................................................................................... 39, 41, 70, 89
ERMFD .................................................................................................. 101
ERMIR ................................................................................................... 101
ET ........................................................................................................... 168
EU ........................................................................................................... 109
219
Event log ................................................................................................ 169

Event Queue Length Maximum ............................................................. 109
Event Queue Overflow Policy ................................................................ 109
Event Queue Used .................................................................................. 109
EX .......................................................................................................... 169
External clock ........................................................................................... 39
External node ............................................................................................ 59
F
Frontend ................................................................................................... 10
Front-end configuration ............................................................................ 36
FS ....................................................................................................... 41, 91
FTAB ...................................................................................................... 152
G
General Object Handling Command ...................................................... 186
GPS ........................................................................................................ 166
H
HB ............................................................................................................ 44
HD .................................................................................................. 113, 169
HE .......................................................................................................... 111
History Buffer .......................................................................................... 44
History Database .................................................................................... 168
History Log Number .............................................................................. 170
HL .......................................................................................................... 170
HM ......................................................................................................... 168
HOST ................................................................................................. 38, 55
Host application ..................................................................................... 106
Host Diagnostics .................................................................................... 113
Host Enabled .......................................................................................... 111
Host Station ............................................................................................ 107
Host station ............................................................................................. 105
HOST_ADDRESS_MISSING ............................................................... 111
HOST1 ..................................................................................................... 66
Hot stand-by ........................................................................................... 125
NET configuration ........................................................................... 135
HOT_SEND ........................................................................................... 135
HP ........................................................................................................... 169
HR .......................................................................................................... 101
HR_CLOCK ........................................................................................... 166
HS ........................................................................................................... 107
HSI (Human System Interface) ................................................................ 11
HT .................................................................................................... 90, 168
I
ID ............................................................................................................ 114
IE ............................................................................................................ 111
220
Image application ................................................................................... 106

Image Diagnostics .................................................................................. 114
Image Enabled ........................................................................................ 111
Image station .......................................................................................... 105
Image Stations ........................................................................................ 107
Image Stations for System Messages ..................................................... 108
IN ............................................................................................................ 137
In Use .............................................................................. 162, 165, 207, 214
Initial mode of NET .................................................................................. 37
Internal NET ............................................................................................. 61
Interoperability ......................................................................................... 13
IS ..................................................................................................... 107, 108
IU .................................................... 30, 84, 89, 90, 149, 162, 165, 207, 214
K
Kernel ......................................................................................................... 9
L
LAN .......................................................................................................... 55
LD ..................................................................................................... 82, 169
LE ............................................................................................................. 92
LF ..................................................................................................... 82, 169
LI .............................................................................. 47, 61, 65, 84, 90, 100
LIN object ................................................................................................. 17
Line ..................................................................................................... 58, 59
Lines per Page ........................................................................................ 169
Link ................................................................................................... 42, 173
LL ..................................................................................................... 82, 169
LMK ....................................................................................................... 211
LONWORKS ................................................................................... 102
Load Control Policy ............................................................................... 110
LOAD_DCP ............................................................................................. 31
Local application ...................................................................................... 43
Local Area Metwork (LAN) ....................................................................... 9
Local Area Network (LAN) ..................................................................... 51
Log .......................................................................................................... 169
Log Directory ......................................................................................... 169
Log Flush Timeout ................................................................................. 169
Log Length ............................................................................................. 169
LonTalk protocol ...................................................................................... 59
LP ................................................................................................... 110, 169
LT ........................................................................................... 61, 84, 89, 90
M
Mail Update Identification ..................................................................... 161
Mapping .................................................................................................... 44
MC ............................................................................................................ 91
Memory allocation .................................................................................... 60
221
Memory area ............................................................................................ 92

Memory tuning ......................................................................................... 44
MEMORY_POOL_ADDRESS ............................................................... 19
MEMORY_POOL_HOLE ....................................................................... 19
MEMORY_POOL_SIZE ......................................................................... 19
Message Application ...................................................................... 161, 163
Message Identification ................................................................... 163, 207
Message split ............................................................................................ 95
MF ............................................................................................................ 45
MFLCONF.DAT .......................................................................... 35, 66, 86
MI ............................................................... 58, 63, 65, 70, 84, 91, 163, 207
MicroPROTOCOL ................................................................................... 51
Mirroring ................................................................................................ 105
Mirroring Role ....................................................................................... 107
MO ............................................................................................. 43, 44, 133
MODE ...................................................................................................... 40
Mode .............................................................................................. 171, 177
MODIFY .................................................................................................. 18
MON ........................................................................................................ 53
MON object .............................................................................................. 17
MR .................................................................................................... 91, 107
MS ........................................ 45, 58, 63, 65, 69, 84, 90, 135, 145, 161, 163
MT .......................................................................................................... 153
MU ................................................................................................... 45, 161
MWCONF.DAT ....................................................................................... 35
N
NA .................................................................. 39, 43, 44, 61, 63, 65, 70, 89
NAK Limit ............................................................................................... 39
ND .......................................................................................... 41, 48, 81, 89
NET .................................................................................................... 10, 12
NET Station addresses ............................................................................. 37
NET_BASCON.COM .............................................................................. 21
NETCONF ............................................................................................... 28
NETn
SSY .................................................................................................... 59
Network
Example .............................................................................................. 71
NN .................................................................................................... 48, 207
NOD ......................................................................................................... 37
NOD object .............................................................................................. 17
Node ........................................................................................... 42, 51, 173
Node number ...................................................................................... 51
Node number of base system ............................................................. 37
Node number of Frontend .................................................................. 36
Node Number ......................................................................................... 207
222
O
OA .......................................................................................................... 163
Object ..................................................................................................... 174
Object Address ....................................................................................... 163
Object number .......................................................................................... 53
OD .................................................................................................... 82, 169
Off-line configuration ............................................................................... 27
OK button ............................................................................................... 204
On-line .................................................................................................... 177
On-line configuration ......................................................................... 27, 29
On-line reconfiguration ............................................................................ 32
Operator workstation ................................................................................ 77
OS ............................................................................................................. 84
Output Destination .................................................................................. 169
P
Parity ......................................................................................................... 39
Paste ........................................................................................................ 183
Paste As Range ....................................................................................... 183
PC ....................................................................................................... 41, 44
pc_net.cf ................................................................................................... 28
PC_NET.CF1 ...................................................................................... 21, 58
PC_NET.COM ......................................................................................... 21
PC-NET .............................................................................................. 21, 28
PC-NETs ................................................................................................... 14
PD ............................................................................................................. 90
Peer node number of NET ........................................................................ 38
PICO_MEMORY_POOL_SIZE .............................................................. 19
Picture Cache Size .................................................................................... 44
PM ...................................................................................................... 44, 86
PO ....................................................................... 63, 65, 69, 84, 86, 89, 164
PO attribute ......................................................................................... 29, 59
PP .............................................................................................................. 90
PQ ............................................................................................................. 44
PR ............................................................................................................. 43
Preconfiguration ....................................................................................... 28
Preview function ..................................................................................... 184
PRI ............................................................................................................ 53
PRI object ................................................................................................. 17
PRIn
SCC ..................................................................................................... 84
SCT ..................................................................................................... 84
SPX ..................................................................................................... 84
PRIN_MEMORY_POOL_SIZE .............................................................. 20
Printer ....................................................................................................... 12
Printer connection ..................................................................................... 79
Process database mirroring ..................................................................... 105
223
Programs ................................................................................................ 184

PROT ............................................................................................ 37, 55, 66
Protection Relay ..................................................................................... 101
Protocol ............................................................................................ 37, 164
PS ..................................................................................... 60, 63, 65, 70, 84
PT ............................................................................................................. 84
PU ........................................................................................................... 165
Pulse Dialing .......................................................................................... 165
PY ........................................................................................... 39, 70, 84, 90
Q
QL ............................................................................................................ 44
QM ........................................................................................................... 82
R
Radio clock ............................................................................................... 12
Radio Connection Wait Time ................................................................. 165
Radio Disconnection Delay .................................................................... 165
RAM size ................................................................................................. 57
RC .............................................................................................. 41, 44, 165
RC attribute .............................................................................................. 26
RD ................................................................................................ 70, 84, 90
RE ............................................................................... 39, 61, 63, 65, 70, 90
Redundancy .............................................................................................. 39
Redundant base system .......................................................................... 125
Redundant Frontend ............................................................................... 144
Remote Calls Enabled ............................................................................ 165
Report Cache Size .................................................................................... 44
REPR_MEMORY_POOL_SIZE ............................................................. 19
REX
LONWORKS ................................................................................... 102
REx Line Number .................................................................................. 207
RF_PRIOBJ ............................................................................................ 150
RF_STAOBJ .......................................................................................... 150
RF_U_CHECK:C ................................................................................... 150
RF_U_LIN:C .......................................................................................... 150
RF_U_NETMS:C ................................................................................... 150
RF_U_ONLC:C ..................................................................................... 151
RF_U_STA:C ......................................................................................... 151
RK ............................................................................................................ 90
RM .......................................................................................... 148, 149, 207
RN ............................................................................................................ 48
RP ............................................................................................................. 90
RS ........................................................................................................... 146
RT ..................................................................................................... 91, 101
RTU configuration ................................................................................. 102
Running Mode ................................................................................ 148, 207
224
RW .......................................................................................................... 165
RX ........................................................................................................... 207
S
S.P.I.D.E.R. RTU ........................................................... 126, 133, 144, 162
Base system configuration .................................................................. 99
NET unit configuration ....................................................................... 99
SA ................................................................. 41, 47, 57, 61, 65, 88, 91, 180
Save Active ............................................................................................. 204
SB ................................................................................................. 70, 84, 90
SC ................................................................................................... 133, 149
SCAN TIME ........................................................................................... 153
SCI .......................................................................................................... 149
SCIL commands ..................................................................................... 204
SCIL Editor ............................................................................................ 184
SCIL errors ............................................................................................. 171
SCIL programs ....................................................................................... 184
SD ............................................................................................... 41, 61, 137
SE ............................................................................. 58, 135, 145, 150, 163
Serial communication ............................................................................... 38
SET ........................................................................................................... 18
SET_CLOCK ......................................................................................... 166
SF .............................................................................................. 86, 126, 133
SH ............................................................................................. 41, 133, 149
SHADGLOBAL ..................................................................................... 137
SHADGOHOT ....................................................................................... 137
SHADMAPMON ................................................................................... 137
SHADMAPNET ..................................................................................... 137
Shadowing .............................................................................. 111, 126, 149
SHADREMHOT .................................................................................... 137
SHADUSR ............................................................................................. 137
Shadusr ................................................................................................... 137
SI ............................................................................................................. 133
Signal ...................................................................................................... 203
Signal Engineering
Station level ...................................................................................... 203
Signal Information .................................................................................. 203
Indicator ............................................................................................ 203
Signal information transfer ..................................................................... 203
signals.ini .................................................................................................. 28
SL ............................................................................................................. 95
SLC-500 ................................................................................................... 87
SN ........................................................................................... 111, 133, 207
SP .................................................................................................. 41, 91, 92
SPA
LONWORKS ................................................................................... 102
SR ........................................................................................... 134, 135, 165
225
SRC .................................................................................................... 36, 66

SRCNOD ............................................................................................ 36, 66
SRIO ......................................................................................................... 87
System parameters ............................................................................. 96
SS ................................................................................................... 133, 163
ST ........................................................................................... 43, 80, 89, 91
STA .......................................................................................................... 53
STA object ............................................................................................... 17
STAn
BND ................................................................................................. 149
Station .................................................................................................... 203
Connecting ......................................................................................... 87
Station Address of Frontend ..................................................................... 36
Station Addresses of Connected Base Systems ........................................ 36
Station Type ........................................................................................... 177
Station Type Definitions ........................................................................ 177
Station types ............................................................................................. 87
Struct input ............................................................................................. 215
SU ............................................................................................... 59, 91, 161
SU attribute .............................................................................................. 60
Subnet Number ....................................................................................... 207
Subtools .................................................................................................. 203
SW .................................................................................................... 59, 133
Switch State ............................................................................................ 163
Switch-over ............................................................................................ 127
SX ................................................................................... 58, 88, 89, 91, 145
SY ........................................................................................... 100, 134, 167
Synchronisation Mode ............................................................................. 40
Synchronise ............................................................................................ 167
SYS
BAA ................................................................................................... 85
BAD ................................................................................................... 85
BCL .................................................................................................... 86
SYS objec ................................................................................................. 17
SYS_BASCON$COM ............................................................................. 21
SYS_BASCON.COM .................................................................. 17, 18, 20
SYS_BASCON.HSB ....................................................................... 21, 127
sys_base.scl .............................................................................................. 28
SYS_CONFIG.PAR ........................................................................... 18, 19
SYS_NETCON.COM .................................................................. 18, 26, 31
SYS_TIME.PAR ...................................................................................... 18
Sysconf.ini ........................................................................................ 28, 176
SYSOLOOCON ..................................................................................... 153
System
Configuration ..................................................................................... 15
Message ............................................................................................ 161
Objects ................................................................................................ 27
226
System Configuration tool ...................................................................... 171

System Message Enabled ....................................................................... 163
T
TCP/IP Host Name ................................................................................... 38
TCP/IP interface ....................................................................................... 38
TD ................................................................................................. 70, 84, 90
TF ............................................................................................................. 41
TI .......................................................................... 39, 41, 61, 63, 65, 89, 90
Time synchronisation ............................................................................. 166
Time zone (minutes) ................................................................................. 40
Timeout Length ........................................................................................ 39
TN ................................................................................................. 48, 81, 89
Translation Type ..................................................................................... 169
TS ............................................................................................................. 92
TT ............................................................................. 44, 48, 77, 81, 89, 169
TZ ............................................................................................................. 41
TZ_MIN ................................................................................................... 40
U
UN ................................................................................ 88, 89, 99, 163, 207
Unit Number ................................................................................... 163, 207
Unit Type ................................................................................................ 207
User-Defined .......................................................................................... 185
User-Defined Programs .......................................................................... 184
UT ........................................................................................................... 207
V
Virtual printer ........................................................................................... 79
W
Watchdog ................................................................................................ 126
Westronic D20 .......................................................................................... 87
Workstation .......................................................................................... 9, 11
227
1MRS751846-MEN EN 03.2005
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

SYS600 System Configuration

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

SYS600 System Configuration

Caricato da

Copyright:

Formati disponibili

MicroSCADA Pro

SYS 600 *9.1

1. About this manual .....................................................................7

©Copyright 2005 ABB Oy, Substation Automation Products, Vaasa, FINLAND 3

12.2.Stations using ANSI X3.28 protocol ........................................... 89

16.5.1.Methods for adding new objects ....................................174

1. About this manual

1.4. Document revisions

Version Revision number Date History

2.1. System description

Process communication system

The process communication is handled by a number of parallel or serially

MicroSCADA System Overview

Base System computer

Fig. 2.1.-1 The main system components of MicroSCADA

Fig. 2.1.-2 An example of a MicroSCADA network. Most configuration

2.2. Configuration principles

Building system configuration

Fig. 2.2.-1 The configuration software modules in MicroSCADA

3. Base system object definitions

Base system objects

Principles for defining base system objects

3.2. Configuration files

If the System Configuration tool is used, the station (STA) objects

sets the size of the global memory pool to 100 MB.

file for a single base system, SYS_BASCON$COM, is during installation copied to

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

#CREATE SYS:B = List(-

#CREATE LIN:V = LIST(- ;Link to DCP-NET (requires DCP driver)

SD = "RM00",- ;DCP card (first:RM00, second RM01)

#CREATE LIN:V = LIST(- ;Link to other SYS or LAN frontend (requires

#CREATE NOD:V = LIST(- ;Node for DCP-NET

#CREATE NOD:V = LIST(- ;Node for LAN frontend or SYS

;#do Read_Text("sys_/pr_default.dat") ;This line is needed for the

#CREATE PRI:V = LIST(-

#CREATE PRI:V = LIST(-

;#CREATE PRI:V = LIST(- ;Required if HP of application is

;#CREATE PRI15:B = %PRI

;The usage of OI & OX -attributes (required by LIB 500)

;Create Application specific global paths

;Add LIB5xx global paths to list if LIB5xx installed

#if substr(SYS:BPR, 1, 7) == "SYS_600" #then #block ; PP

;Add SA_LIB global paths to list

#CREATE APL:V = LIST(-

;#CREATE APL:V = LIST(- ;LIB5xx Demo Application

#SET STY3:BCX = "ANSI X3-28"

#CREATE STY25:B = LIST(NA = "PCO", DB = "STA", CX = "Procontic / RCOM")

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

;NET 1 (DCP-NET) stations

If the MicroSCADA base system revision 8.4.2 or later is used

#CREATE APL:V = LIST(-

4. Communication system object definitions

Communication system objects

Defining communication system objects

4.2. Defining communication system objects off-line

Preconfiguration with the system configuration tool

PC-NET configuration with the System Configuration Tool

Initialization file of the PC-NET

4.3. Defining communication system objects on-line

Modifying communication system objects with SCIL

Only NET objects can be configured in SYS_NETCON.COM.

The SYS_NETCON.COM file can be edited with a text editor in Windows

NET start-up configuration with SCIL

NET start-up configuration with the System Configuration Tool