Micros A Cada
Micros A Cada
2
System Configuration Configuration Manual
1MRS756112
Issued: 31.12.2007 Version: B/31.12.2007
Contents
Copyrights ................................................................................. 9 1. Introduction............................................................ 11
1.1. 1.2. 1.3. 1.4. 1.5. 1.6. This manual.............................................................11 Use of symbols ........................................................11 Intended audience ....................................................11 Product documentation ............................................. 12 Document conventions ............................................. 12 Document revisions.................................................. 13 15 16 17 18 18 19 19 19 19 20 21 21 22 22 22 22 22 23 23 23 23 23 24 24 24 24 25 25 26 26 27 27
3
1MRS756112
2.11.
2.12.
2.16.
2.10.2. Data processing .......................................... 2.10.3. Trends ....................................................... 2.10.4. Measurement reports.................................... 2.10.5. Localization................................................. Time synchronization................................................ 2.11.1. GPS .......................................................... 2.11.2. DCF77 ....................................................... Redundancy ........................................................... 2.12.1. Server redundancy....................................... 2.12.2. Communication redundancy........................... Mirroring................................................................. OPC connectivity ..................................................... Capacity and performance scalability .......................... 2.15.1. Computer capacity ....................................... 2.15.2. Distributing processing capacity ..................... Product licensing .....................................................
27 27 28 28 29 29 30 31 31 31 32 32 33 33 34 35 37 39 39 39 44 47 48 48 49 50 50 50 51 54 56 57 58 59 65 68 69 69 71 71 76
3. Configuration.......................................................... 37
3.1. Configuring system server ......................................... 3.1.1. Hardware and operating system ..................... 3.1.2. Base system (SYS)...................................... 3.1.2.1. Base system objects ...................... 3.1.2.2. Memory configuration ..................... 3.1.3. Applications (APL) ....................................... 3.1.3.1. Configuring APL objects ................. 3.1.3.2. Mapping devices ........................... 3.1.3.3. Adding applications........................ 3.1.3.4. Removing applications ................... 3.1.4. Configuring license protection ........................ 3.2. Configuring workplaces............................................. 3.2.1. Windows terminal server ............................... 3.2.2. Citrix MetaFrame Application Server ............... 3.2.2.1. Verifying client connections ............. 3.2.3. WinnConn XP Server/BeTwin ........................ 3.2.4. Defining MON objects................................... 3.2.5. Monitor Pro configuration .............................. 3.2.5.1. OpenRemoteDesktop ..................... 3.2.6. Audible alarm raising and acknowledgement .... 3.3. Configuring process communication ............................ 3.3.1. Configuring communication system objects in base system ............................................... 3.3.2. Configuring process communication units ........ 3.3.2.1. Configuring PC-NET ...................... 3.3.2.2. Configuring IEC 61850 with External OPC DA Client .................
4
1MRS756112
3.4.
3.5.
3.6.
3.7.
3.8.
3.9.
Configuring CDC-II slave ................ 77 Configuring Modbus slave............... 77 Configuring CPI-connected applications .................................. 77 3.3.2.6. Selected configuration examples for PC-NET .................................. 78 3.3.3. Distributed process communication units ......... 91 3.3.3.1. Distributed PC-NETs ...................... 92 Configuring System Self Supervision........................... 94 3.4.1. Configuring application objects....................... 95 3.4.2. Configuring communication engines for binary supervision information ................................. 96 3.4.3. Configuring supervision symbols .................... 96 3.4.4. Configuring dynamics for supervision symbols... 97 Configuring communication gateway ........................... 98 3.5.1. SYS_BASCON.COM modifications ................. 98 3.5.2. Gateway license .......................................... 99 Configuring peripheral equipment ............................... 99 3.6.1. Configuring printers ...................................... 99 3.6.1.1. LAN connection ............................ 99 3.6.1.2. NET connection............................100 3.6.2. Configuring I/O adapter cards .......................102 Configuring time handling.........................................104 3.7.1. Configuring time synchronization ...................105 3.7.1.1. Configuring external clocks ............106 3.7.2. Configuring time zone and daylight saving .....107 3.7.3. Time zone and daylight saving history ............107 3.7.4. Configuring representation of dates................108 Configuring networks............................................... 110 3.8.1. Configuring Local Area Networks (LAN).......... 112 3.8.2. Communicating between applications ............. 113 3.8.2.1. Local applications......................... 113 3.8.2.2. Applications in separate base systems ...................................... 114 Configuring redundancy ........................................... 116 3.9.1. Hot stand-by base systems .......................... 116 3.9.1.1. Configuring hot stand-by systems.... 116 3.9.1.2. SYS_BASCON.HSB ..................... 117 3.9.1.3. Watchdog application ....................123 3.9.1.4. Shadowing ..................................125 3.9.2. Hot stand-by with OPC client and servers .......126
1MRS756112
Starting an External OPC Data Access Client...............................126 3.9.2.2. Activating station communication.....127 3.9.3. Hot stand-by with PC-NET ...........................127 3.9.3.1. PC-NET configuration....................127 3.9.3.2. Activating communication...............128 3.9.3.3. Deactivating communication ...........129 3.9.4. Hot stand-by with CDC-II slave .....................129 3.9.5. Hot stand-by with Modbus slave....................130 3.9.5.1. Modbus slave configuration............130 3.9.5.2. Activating communication...............131 3.9.5.3. Deactivating communication ...........132 3.9.6. Hot stand-by with CPI applications.................132 3.9.7. Hot stand-by with communication gateway COM 500i..................................................133 3.9.7.1. Configuring communication gateway COM 500i .......................134 3.10. Configuring mirroring ...............................................136 3.10.1. Station mapping .........................................137 3.10.2. Process messages......................................138 3.10.3. Process commands.....................................138 3.10.4. System object (STA:S) communication ...........138 3.10.5. System messages ......................................139 3.10.6. Subscriptions .............................................139 3.10.7. Buffering and communication breaks..............140 3.10.8. Hot stand-by ..............................................141 3.10.9. Disabling mirroring ......................................142 3.10.10. Application events.......................................142 3.10.11. Configuration examples ...............................144 3.10.11.1. Example 1: One host, one image ....145 3.10.11.2. Example 2: Two hosts, redundant image .........................................147 3.10.11.3. Example 3: Station numbering convention in a mirroring system.....149 3.10.11.4. Example 4: Local mirroring.............151 3.10.11.5. Example 5: Hierarchical mirroring....152 3.11. Configuring OPC connectivity ...................................154 3.11.1. DCOM settings...........................................154 3.11.1.1. Enabling of Distributed COM ..........155 3.11.1.2. Defining access permissions ..........155 3.11.1.3. Defining launch and activation permissions .................................155
3.9.2.1.
1MRS756112
3.11.1.4. Defining DCOM settings for OPC server.........................................156 3.11.1.5. Defining DCOM settings for OPC Server Enumerator .......................156 3.11.2. Local Security Policy settings........................157
1MRS756112
4.3.2. 4.3.3.
1MRS756112
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 2007 ABB. All rights reserved.
Trademarks
ABB is a registered trademark of ABB Group. All other brand or product names mentioned in this document may be trademarks or registered trademarks of their respective holders.
Guarantee
Please inquire about the terms of guarantee from your nearest ABB representative.
10
1MRS756112
1.
1.1.
Introduction
This manual
This manual provides thorough information on the various configuration settings that you have to make in order to use your SYS 600 system. The manual also describes how to use the configuration tools.
1.2.
Use of symbols
This publication includes the following icons that point out safety-related conditions or other important information: The caution icon indicates important information or warning related to the concept discussed in the text. It might indicate the presence of a hazard which could result in corruption of software or damage to equipment or property.
The information icon alerts the reader to relevant facts and conditions.
It should be understood that operation of damaged equipment could, under certain operational conditions, result in degraded process performance leading to information or property loss. Therefore, comply fully with all notices.
1.3.
Intended audience
This manual is intended for engineers to support configuration and engineering of systems and/or applications.
11
1MRS756112
1.4.
Product documentation
Name of the document Application Design Application Objects Communication Programming Interface (CPI) Connecting LONWORKS Devices IEC 60870-5-101 Slave Protocol IEC 60870-5-104 Slave Protocol IEC 61850 System Design External OPC Data Access Client Programming Language SCIL System Objects IEC 61850 Master Protocol (OPC) LIB 500 *4.2. Operation Manual RER 111 Technical Reference Manual SPA-ZC 400, SPA to IEC 61850 Gateway, Installation and Commissioning Manual Visual SCIL Application Design Visual SCIL Objects CDC-II Slave Protocol Process Display Design Modbus Slave Protocol Document ID 1MRS756170 1MRS756175 1MRS756127 1MRS756154 1MRS756159 1MRS756162 1MRS756119 1MRS756163 1MRS756176 1MRS756177 1MRS756230 1MRS755359 1MRS750104-MUM 1MRS755347 1MRS756184 1MRS756171 1MRS756188 1MRS756117 1MRS756168
Microsoft Windows Server 2003 Terminal Server licensing manual MMC500_TS.CMD in the Microsoft Windows Server 2003 Terminal Server installation Manual
1.5.
Document conventions
The following conventions are used for the presentation of material:
*
* *
* *
The words in names of screen elements (for example, the title in the title bar of a dialog, the label for a field of a dialog box) are initially capitalized. Capital letters are used for file names. Capital letters are used for the name of a keyboard key if it is labeled on the keyboard. For example, press the CTRL key. Although the Enter and Shift keys are not labeled they are written in capital letters, e.g. press ENTER. Lowercase letters are used for the name of a keyboard key that is not labeled on the keyboard. For example, the space bar, comma key and so on. Press CTRL+C indicates that you must hold down the CTRL key while pressing the C key (to copy a selected object in this case). Press ALT E C indicates that you press and release each key in sequence (to copy a selected object in this case). The names of push and toggle buttons are boldfaced. For example, click OK. The names of menus and menu items are boldfaced. For example, the File menu.
12
1MRS756112
* *
The following convention is used for menu operations: Menu Name > Menu Item > Cascaded Menu Item. For example: select File > Open > New Project. The Start menu name always refers to the Start menu on the Windows Task Bar. System prompts/messages and user responses/input are shown in the Courier font. For example, if you enter a value out of range, the following message is displayed: Entered value is not valid. You may be told to enter the string MIF349 in a field. The string is shown as follows in the procedure: MIF349
1.6.
Document revisions
Version A B Software revision number 9.2 9.2 Date 27.07.2007 31.12.2007 History Document created Document updated
13
14
1MRS756112
2.
2.1.
System architecture
The main components of a SYS 600 system are:
* * * * * *
System servers Communication servers Workstations Peripheral equipment including printers, GPS clocks, alarm devices Communication equipment including switches, routers, modems IEDs, process devices, data acquisition units, RTUs, PLCs and so on
The different system components can be used to build everything including the following:
*
A small single computer monitoring system, for example, embedded in a panel PC with touch screen mounted in the door of a cubicle (as shown in Fig. 2.1.-1) A hierarchical system in several levels with redundant servers (as shown in Fig. 2.1.-2)
A070742
Fig. 2.1.-1
15
1MRS756112
A070743
Fig. 2.1.-2
2.2.
System server
Most of the different functions in SYS 600 are handled by the system server. In each system server, there is one base system that is responsible for the central data processing services. Each base system can include one or several applications, as shown in Fig. 2.2.-1. The application defines the automation functionality and user interface, by its own real-time process database, history database, displays and so on. The applications are independent from each other, although they can interact with each other. A typical single computer SA system has one system server with one base system and one application, whereas a large distributed control system can have several servers with several applications each. The applications can be divided according to:
* *
application area (for example, electricity or district heating) tasks (for example, reporting, process display handling, communication gateway)
16
1MRS756112
A070744
Fig. 2.2.-1
The system server can also include the communication services needed for the remote communication (communication with an upper level system) and the process communication (communication with the process or lower level systems). However, these services can also be located in separate communication servers. The system server also supports redundancy by a hot stand-by concept for the applications, and with the help of it the availability of the system can be improved.
2.2.1.
Application examples
Application examples are shown in the following figures:
A070745
Fig. 2.2.1.-1
17
1MRS756112
A071116
Fig. 2.2.1.-2
A071117
Fig. 2.2.1.-3
2.2.2.
System objects
The components of the system and the system server is configured and managed by means of System objects. There is a system object for each connected station (IEDs, RTUs and so on), printer, system node (base system, PC-NET, OPC servers and so on) and application. The most important system object types are listed below:
* * * * * * *
The system objects have a number of attributes that are use for configuring and monitoring of the system. The system objects are created and managed by SCIL. For more information, refer to the System Objects manual.
2.2.3.
Application objects
Each application contains a number of various application objects. The application objects define the behavior of the application. The application object types are listed below:
18
1MRS756112
Process objects (and free type process objects) Event handling objects Scales Time channels Event channels Command procedures Data objects
2.2.4.
2.2.5.
Process database
The process database is the storage for all process data related application objects. These are process objects, scales, event handling objects and free type process objects. The process database is a high performance and high capacity real time database that is maintenance free and can be configured online. The objects are created, deleted and managed with SCIL and with dedicated tools. For more information, refer to the Application Objects manual.
2.2.6.
Report database
The report database is the storage for all reporting, calculation and data processing related application objects. These objects are: Time channels, Event channels, Command procedures and Data objects. For more information, refer to the Application Objects manual.
2.3.
Process communication
The task of the process communication is to form a communication link between the SYS 600 system server and various process devices, like IEDs, RTUs, PLC and so on. The communication with the process devices uses various types of protocols like
19
1MRS756112
IEC 60870-5-10x, IEC 61850, DNP, Modbus, LON, SPA and so on. Each protocol has its own characteristics and the physical media and interfaces have to be built accordingly. The software interface in SYS 600 is handled by a communication unit. The communication unit is dependent on the protocol that is used. The most common communication units are the PC-NET and the IEC 61850 OPC Server/External OPC DA Client. The PC-NET is used with most of the SYS 600 protocols, except IEC 61850, which is handled by the IEC 61850 OPC Server and the External OPC DA Client. The process communication can be integrated in the system server in compact systems and it can also be allocated to dedicated communication servers.
2.3.1.
Communication servers
The communication services can be allocated to dedicated communication servers. This can be done under the following circumstances:
*
* *
When higher capacity and performance is needed than what one server with everything integrated can handle When more hardware interfaces are needed, for example, serial ports or LON interfaces To minimize impact of hardware failure When redundant communication servers are required
The communication server typically communicates with the systems server over LAN. The communication server always includes one or several communication units (PC-NET, IEC 61850 OPC Server); but it can also be configured to include its own process database. When it includes its own process database, it communicates with the system server(s) by means of the process data mirroring function. The reasons for including the process database could be one of the following:
* *
The communication server provides data to several system servers Higher buffering capacity of the data between the communication server and the system server is needed Local data processing in the communication server is required
The communication servers can be implemented both as a single computer and as a hot stand-by pair. The components of the communication server vary depending on the used protocols and on the overall system architecture. The most important components are:
*
PC-NET It includes protocol drivers for all supported protocols, except IEC 61850 (and those implemented with CPI).
* *
20
1MRS756112
It is an IEC 61850 client that is connected to SYS 600 base system over OPC.
*
External OPC DA Client The OPC DA Client that is used to connect the IEC 61850 OPC Server to the base system.
2.4.
Communication gateway
The communication gateway is a system server with an application, that routes messages from the process communication to the remote communication and vice versa. The gateway application is called COM 500i. The communication gateway can have the communication services integrated in it or can also use external communication servers for process communication. It can be configured in hot stand-by mode. The application can be freely combined with any other system server functionality including reporting, process displays and IED tools.
2.5.
Workplaces
The workplace provides the means for the operator to configure the system, and at the same time, supervise and interact with the process with the help of the graphical user interface (GUI). The workplace is always connected to a system server. Each system server can have its local workplace but the workplaces can also be distributed to other computers and locations. The computer, in which the workplace is used, is called workstation. The system supports two different types of workplaces: the classic workplace and the pro workplace. The classic workplace refers to the workplace technology used in earlier versions of the product, while the pro workplace refers to the workplace concept introduced with SYS 600 9.x. The classic workplace is supported to provide full compatibility and easy migration from older product versions to newer. Each system server can have up to 50 pro workplaces and/or 100 classic workplaces simultaneously in use. The workstations can be distributed over a network using TCP/IP. It can be a LAN, internet or mobile wireless communication. Each workplace can be used for engineering, supervision and operation of the process. The possibilities are defined by the access rights given to the user in question. Also the layout and functions of the workplaces can be fully customized for each user. The distributed classic workplace is based on the X-window technique and uses the Exceed X-server emulator in the workstation. The pro workplace concept is based on available remote access techniques, typically Microsofts Terminal Server or Citrix Access Essentials. Any PC or other web enabled device can hence be used as a workstation without installing any additional software.
21
1MRS756112
2.6.
Peripheral equipment
Various peripheral equipment can be connected to the system. The most typical ones are listed below:
* * * *
2.6.1.
Printers
The printers can be connected to the system server either directly, over a LAN via printer servers, or via the process communication system. A base system can have up to 20 printers of different types: it can be a matrix printer, or a laser printer. Printers can be allocated for different tasks, including alarm and event printout, hard copy, and historical reports. It can be programmed to take over the tasks of another printer automatically. Printouts can be produced automatically or manually. The layout of a printout can be customized. The main printout types are logs, reports, hard copies and documents. Logs are automatic printouts based on process events. The logs can be directed to one or more printers.
2.6.2.
2.6.3.
GPS clocks
For accurate time synchronization, one or several GPS clocks can be connected to the system. The clock can be connected directly over LAN, using standard Operating System functions, or it can be connected via the process communication bus, for example, over IEC 61850.
2.6.4.
Service modems
A possible service modem can be connected to the system. This can provide remote access to the system, for example, over the public telephone network. The remote access can be used for monitoring, fault analysis and maintenance of the system.
22
1MRS756112
2.7.
2.8.
Event handling
An event is a kind of change in the process or in the system, that occurs at a certain moment in time. Event can be caused by changes in the process, actions performed by the user, faults in the system and so on.
2.8.1.
Data collection
All data related to the controlled process, including status indications, measurements and commands, are managed by the process database. In addition to these, data related to the system itself, connected IEDs, RTUs, peripheral equipment, user activities and so on can be collected into the process database. Each signal is represented by a process object in the database. In addition to the object value, the process object holds a number of attributes that gives more information about the value, as well as describes how events are generated based on changes in the process object.
2.8.2.
Time tagging
Each process object has a time tag that tells when the object was updated. The time tag typically originates from the source of the data, for example, IED, RTU, and so on. Only if the device, that collects the data, does not support time tags, or if the used communication protocol does not support time tags, then the system itself gives the time tag. The time tag resolution is 1 ms, but the accuracy depends on the time accuracy of the data source.
2.8.3.
Criteria * New value * Updated value * Value goes up/down * Warning state reached
23
1MRS756112
Alarm state reached * Alarm acknowledged Actions * Event logging * Activation of freely configurable post-processing * The freely configurable post-processing can basically initiate any type of activity in the system * Printouts
*
2.8.4.
Event descriptions
The system also contains descriptive information about each event. This information is shown in the event list. The descriptive information can be formed from two different texts: the state text and the message text. The state text described the current object state and is dependent on the object value. The state text can however also take into account any other attribute of the process object in order to exactly describe the situation. The message text is formed based on the object value transition, both the old value and the new value. The event descriptions are defined by event handling objects in the process database. Each process object is associated with an event handling object.
2.8.5.
Event logging
All events, that are defined to be logged, are stored in an event database. The capacity of the event database is only limited by the disk storage capacity. Most process object attributes are stored with each event to enable exact post-analysis of the process state.
2.8.6.
Event post-processing
It is possible to initiate some post-processing at an event. The post-processing is implemented by a SCIL program, that can perform any type of tasks, including reading a disturbance record file from an IED, opening a display, starting a command sequence, sending data to another system and starting an external program.
2.8.7.
Event display
The event display shows events stored in the event database, as shown in Fig. 2.8.7.-1. It supports easy sorting and filtering of the events to make the event analysis as easy as possible. It can also be freely configured to display the information, the layout and colouring of the events.
24
1MRS756112
It is also possible to have predefined filters that are easily accessed from toolbars and menus.
A071118
Fig. 2.8.7.-1
Event display
2.9. 2.9.1.
Active (or persisting) * The alarm state is active but the alarm does not need to be acknowledged Active unacknowledged * The alarm state is active but not yet acknowledged Active acknowledged * The alarm state is active and acknowledged Fleeting * The alarm state is no longer active but has not been acknowledged after it became active
The state transitions of an alarm can cause an event in the system, as well as the acknowledgements. In this way, it is possible to analyze the alarm state history with the help of the event display. With proper filtering, the event list can show all alarm activations, deactivations and acknowledgements.
25
1MRS756112
2.9.2.
Alarm indication
Alarming signals are represented in various ways in the system. The alarm state information is always available in the process database and can be used for any type of alarm representation. The most typical signals are listed below:
* *
* * *
A specific representation in the process display, for example, a blinking symbol The signal representation is colored red, for example, in process displays, lists, dialogs and so on An audio signal is played, for example, a horn or sound file of the computer The alarm is displayed in the alarm display The alarm is displayed in the object dialog of the concerned object
2.9.3.
Alarm display
The alarm display shows the alarms of the system in a list, as shown in Fig. 2.9.3.-1. It supports easy sorting and filtering of the events to make the alarm analysis as easy as possible. It can also be freely configured to display the information, the layout and coloring of the alarms. It is also possible to have predefined filters that can be easily accessed from toolbars and menus.
A071119
Fig. 2.9.3.-1
Alarm display
26
1MRS756112
2.10. 2.10.1.
2.10.2.
Data processing
All data objects are fully accessible with SCIL so further data processing can be achieved by SCIL programming. In this way, further data analysis and refinement can be achieved to calculate forecasts, trends, various statistics and so on. The result of the calculations can also be stored in data objects for visualization or other needs.
2.10.3.
Trends
The trend display is an application that collects data and visualizes the data in numerical or graphical form. It is used for follow up and analysis of data in time frames from minutes to one month. The data is logged cyclically in intervals of 30 seconds, 1, 2, 5 or 10 minutes. The trend display can log and show any type of data available in the process database.
27
1MRS756112
2.10.4.
Measurement reports
The measurement reports display is also an application that collects data and visualizes the data in numerical or graphical form. The measurement reports display is used to log and report data during longer periods than the Trend Application, and it is dedicated for Energy, Current, Voltage, Temperature and Frequency reports. The available time ranges for the reports are listed below:
* * * * * * *
Hourly report (time resolution: 3 minutes) Daily report (time resolution: 15 minutes) Daily report (time resolution: 30 minutes) Daily report (time resolution: 60 minutes) Weekly report (time resolution: 1 day) Monthly report (time resolution: 1 day) Yearly report (time resolution: 1 month)
The storage period for the reports can be up to 5 years. Longer storage periods can be custom built or achieved by exporting data to an external reporting database.
A071131
Fig. 2.10.4.-1
2.10.5.
Localization
It is possible to translate the user interface to any language that can fit into the boundaries of the graphical user interface, that is, size, position and direction of texts and icons. The system also supports several languages simultaneously enabling operators to work with the system in his native language. The language is part of the user profile and is selected automatically while login to the system.
28
1MRS756112
2.11.
Time synchronization
In a SYS 600 system, a synchronized clock between SYS 600 and all connected devices and IEDs is crucial for exact event and data analysis. All data, collected from the process, is time tagged as close to the process as possible, for example, in the IED, for highest possible accuracy. The time tag of the data follows the data through out the system, that is, from the source to the Substation Automation system and up to the Network Control system. But SYS 600 also needs to be synchronized, because all operations initiated from SYS 600, are time tagged. In case, if there are IEDs or protocols that do not support time tagging, SYS 600 will handle the time tagging. Today, most systems need to be quite accurately synchronized with the absolute time, and this requires some external time source. The most common time sources are GPS and DCF77. Also if SYS 600 is used at Substation level, it can be synchronized by the Network Control system over the remote protocol.
2.11.1.
GPS
The GPS time can be used to synchronize the computer in various ways; the most common ways are listed below:
* * *
When the GPS clock is connected to the LAN, it communicates with the SYS 600 computer using SNTP (Simple Network Time Protocol). The SNTP is needed, as there is a SNTP client in the computer that synchronizes the internal clock. If IEC 61850 is used in the system, the IEC 61850 client can also act as a SNTP client. If IEC 61850 is not used, an external SNTP client has to be used. Alternatives are Tardis2000, Yats32 Synchronization applications and Trimble Ace III. It is preferable to connect the GPS over LAN in IEC 61850 systems, because then the same clock can be used to synchronize the IEDs.
The GPS clock can also be connected to a serial port of the computer. In this case the clock manufacturer provides driver that handles the synchronization of the computer clock. One example is Meinberg GPS 167, as shown in Fig. 2.11.1.-1.
A070485
Fig. 2.11.1.-1
29
1MRS756112
The GPS signal can also be handled by a dedicated PC Card. Also in this case the manufacturer provides a driver that handles the synchronization of the computer clock. The GPS170PCI card, as shown in Fig. 2.11.1.-2, synchronizes the system time of computers with PCI/PCI-X bus interface.
A070484
Fig. 2.11.1.-2
The accuracy of the time depends on the components participating in the synchronization, including the receiver, the SNTP client and the internal clock of the computer. Typically an accuracy of +- 1 ms can be reached.
2.11.2.
DCF77
DCF77 is a radio signal that can be used to synchronize the computer. The DCF77 radio receiver, the Meinbergs board PCI511, as shown in Fig. 2.11.2.-1, has been designed for the reception of the DCF77 signal, to transfer the time information to a computer with PCI (PCI-X) bus interface and the translation of the received codes into a serial telegram.
30
1MRS756112
A070483
Fig. 2.11.2.-1
Meinberg's PCI511
2.12. 2.12.1.
2.12.2.
Communication redundancy
Redundant communication lines means that two or several connections between the master and the slave form one logical connection. One of the connections is active and if the active connection fails another connection is used instead.
31
1MRS756112
Redundant communication lines are supported for IEC 60870-7-101 slave, RP-570 slave and IEC 60870-7-104 master and slave.
2.13.
Mirroring
The process data mirroring provides a powerful means for sharing process data in a SYS 600 network with minimal engineering effort. This can be used to build hierarchical systems, for example, with one main control center, a number of regional control centers and more local control centers or substations. It can also be used for load distribution in large systems. The data mirroring can also be used to share data between a SYS 600 HMI and SYS 600 Gateway (COM 500i), for example, when communication protocols are used that can have only one master. Mirroring can even be used to share process data among totally different kinds of applications. For example, electrical SCADA and district heating SCADA can share some indications, measurements and events. The advantage of using data mirroring instead of standard communication like IEC 60870-5-104 is that, the data mirroring communication is much more efficient and the required engineering work to build up the system is minimal. In addition, several special functions, such as event buffering during communication breaks and handling of hot stand-by configurations, are automatically taken care of. The data mirroring takes place between a Host and an Image. The Host is the source for the process data and the Image is a copy of the process data. The SYS 600 node that receives the process data, for example, through IEC 61850 or LON is the Host. This process data can be mirrored to another SYS 600 node which acts as an Image. The data mirroring function is defined per SYS 600 Station object (STA). When a station is configured for data mirroring, all process objects connected to that station are mirrored according to the mirroring definitions of that station. Each station can only have one source for the process data, either the process itself or a Host station in another SYS 600 node. But the process data of one station can be mirrored to 110 Image stations. A station can also act both as Image and Host. In this way a hierarchical system in several levels can be built up. Although the mirroring typically takes place between different computers, it is also possible to mirror data from one application to another in the same base system.
2.14.
OPC connectivity
OPC is a de-facto interface standard when connecting various devices and systems within the process automation industry. OPC is also becoming more and more used and accepted also in other application areas and within the power industry. It defines the exchange of data between a server and a client. The server provides data and the client uses the data. The client can also write data (commands, parameters and so on) to the server.
32
1MRS756112
SYS 600 provides OPC connectivity both in forms of clients and servers, that is, SYS 600 can receive data from a device or system that provides its data through an OPC server, as shown in Fig. 2.14.-1. SYS 600 can also provide its data to another system that acts as a client.
A070736
Fig. 2.14.-1
OPC connectivity
2.15.
by using computer(s) with various processing capacity by using various numbers of computers
2.15.1.
Computer capacity
The computer type can be selected in order to match the capacity requirements of the system. The most important parameters are listed below:
* * *
33
1MRS756112
The most important system characteristics, that should be considered when designing the system are listed below:
* * * *
Process communication load Number of simultaneous workplaces Intensity of archiving, calculations and reporting Possible other system specific functions
2.15.2.
Workstation Server
Fig. 2.15.2.-1
34
1MRS756112
Fig. 2.15.2.-1 is an example of a system where different functions have been distributed to achieve a higher capacity. The process image of the system server can be mirrored up to ten different servers. The number of communication front-ends connected to the system server is mainly limited by practical factors and the system server capacity. All nodes connected to the system by means of the mirroring functionality have SYS 600 installed.
Operator Workstations
Fig. 2.15.2.-2
The communication front-end can also be distributed in other ways, depending on the communication protocols used. In an IEC 61850 system, the External OPC DA Client and the IEC 61850 OPC server can run in its own computer. In addition to that, protocols or protocol converters implemented with CPI (Communication Programming Interface), can run in its own computer. For more information on building the IEC 61850 system, refer to IEC 61850 System Design manual.
2.16.
Product licensing
The functionality of the SYS 600 product is dependent on the product license. The license describes about the functions that can be used, the size or capacity of a specific function, as well as, the time during which the product can be used. The license is delivered as a paf file (product authorization file) and is installed in the product by means of a dedicated tool. The license is locked to a specific hardware with the help of one or several hardware keys. The license includes information about which hardware keys that are used. If one of the specified hardware keys is present the license is enabled. If the hardware keys are missing the license is disabled. The hardware key is a USB stick that is installed into a USB port of the computer. The hardware keys are identified by a unique ID number that is printed on the USB stick. The corresponding number is also used in the license.
35
1MRS756112
The License can define if the hardware key is installed in the local computer or in another SYS 600 computer in the same SYS 600 network. If the hardware lock becomes invalid during operation, SYS 600 will work without restrictions for one week. During this time, the hardware lock should be fixed. The following changes in the status of the hardware lock are reported: 1. Changes in the status of the hardware lock: valid <-> invalid 2. Missing hardware key 3. Found hardware key
36
1MRS756112
3.
Configuration
The SYS 600 system configuration is composed of objects and definitions for the base systems and process communication units, as shown in Fig. 3.1.-1. The main components for the configuration are the following:
*
Each base system contains a set of base system objects that specify the base system itself and its environment. During the operation, the base system objects are in the primary memory of the base system computer. The base system objects are created with SCIL commands when the MicroSCADA Pro base system is started. They can be added and modified during the operation. Each process communication unit contains a set of system objects that specify the unit itself and its environment. During the operation, the system objects are in the memory of the PC (for example, process communication type PC-NET). Typically these system objects has been configured by the SCIL programs. Otherwise the default values given by the process communication units will be applied. The system objects can be added and modified during the system operation. Process communication units of type IEC 61850 with External OPC DA Client are configured using the Communication Engineering Tool for IEC 61850 OPC Server.
3.1.
base system which uses it: base system objects. 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 Pro system configuration can be changed any time. However, in some cases, like when a new station is added to the system, a shutdown and restart is required for activating the changes.
37
1MRS756112
A051598
Fig. 3.1.-1
38
1MRS756112
3.1.1.
SYS600
VS type monitor
A070491
Fig. 3.1.1.-1
MicroSCADA Pro supports Intel x86 compatible processors and Microsofts x32 (32-bit) compatible operating systems: Windows XP, Windows 2000 Server and Windows Server 2003. For information on requirements, refer to Installation and Administration Manual. MicroSCADA Pro can be installed as part of Windows domain, but it cannot be installed to the domain server. A Windows domain is a logical grouping of computers that share common security and user account information. This information is stored in a master directory database (SAM) which resides on a Windows server designated as a domain controller. We recommend to use MicroSCADA in a stand-alone server to avoid complicated errors.
3.1.2.
3.1.2.1.
39
1MRS756112
one for configuring a hot stand-by base system. During installation, the template file for a single base system, SYS_BASCON$COM, is copied to SYS_BASCON.COM if the SYS_BASCON.COM does not previously exist. The template file for hot stand-by systems is SYS_BASCON.HSB. The SYS_BASCON$COM template file defines a system configuration as presented in Fig. 3.1.2.1.-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. It is required if HP (History Logging Policy) of the application is "EVENT LOG". The base system has two communication links to NET nodes. One node is connected to the TCP/IP LAN link. The other node, which is running the PC-NET communication software, is connected over an integrated link to the base system. The configuration allows ten classic monitors to open to the TUTOR application.
A051601
Fig. 3.1.2.1.-1
The contents of the SYS_BASCON$COM file is listed below. Some configuration definitions have been excluded by commenting them. They can be taken into use by removing the comment sign (;) in front of the SCIL lines that creates the base system object. To edit the current SYS_BASCON.COM, open the MicroSCADA Control Panel > Admin > 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
40
1MRS756112
@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: for example, 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 informatio 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, 2=INFORMATION, -; 3=AUDIT_SUCCESS, 4=AUDIT_FAILURE) Bit_Mask(0,1,2,3,4)),- ;Security events (Bit 0=ERROR, 1=WARNING, 2=INFORMATION, -; 3=AUDIT_SUCCESS, 4=AUDIT_FAILURE) 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 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(LT = "LAN") ;Link type ;#CREATE LIN2:B = %LIN ;Link to other SYS or LAN frontend (requires TCP/IP)
; ;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(LI = 2,SA = 202) ;#CREATE NOD2:B = %NOD ;Node for LAN frontend or SYS
; ;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
41
1MRS756112
#CREATE PRI:V = LIST(TT = "LOCAL",DT = "NORMAL",DC = "LINE",SD = "\\My_NT\My_Printer",LP = 66) ;#CREATE PRI2:B = %PRI #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 PRI3:B = %PRI ;#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) ;#CREATE PRI15:B = %PRI ; ;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
42
1MRS756112
;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 #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 = 16,;Number of parallel queues/ Needed in COM500i Applications -; QD = (1,1,0,0,0,0,1,1,1,1,1,1,1,1,1,1),- ;Parallel queue dedication/Needed in COM500i -; Applications SV = %SV,;System variable (RESERVED) CP = "SHARED",- ;Color Allocation Policy 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", #CREATE STY23:B = LIST(NA = "LMK", DB = "REX", #CREATE STY24:B = LIST(NA = "ADE", DB = "STA", #CREATE STY25:B = LIST(NA = "PCO", DB = "STA", #CREATE STY26:B = LIST(NA = "WES", DB = "STA", #CREATE STY27:B = LIST(NA = "ATR", DB = "STA", #CREATE STY28:B = LIST(NA = "PLC", DB = "RTU", #SET STY29:BCX = "IEC 60870-5-10x" #SET STY30:BCX = "DNP V3.00" #SET STY33:BCX = "OPC Alarm Event Server"
CX CX CX CX CX CX CX
= = = = = = =
; ;Node, Link for PC-NET Stations @i_Status = do (read_text("Sys_Tool/Create_C.scl"), "BASE_SYSTEM") ; ;LAN node name of the computer
43
1MRS756112
; ;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
The SYS:B object definition should come first in the base system configuration file SYS_BASCON.COM, otherwise the system does not start.
If there is a configuration error in the SYS_BASCON.COM file, the system might not start. Check the messages from the Notification Window or SYS_ERROR.LOG.
3.1.2.2.
Memory configuration
The SYS 600 base system applies the policy of pre-allocating the virtual memory to be used during the whole session. Pre-allocation of virtual memory is a usability issue: it ensures that the system or a monitor, once successfully started, is able to request the memory resources it needs, whatever happens in the system. Memory allocation by demand happens in the system, may cause the computer to run in "Virtual memory low" state, which severely degrades the performance and, in the worst case, makes the system totally unusable.
Memory pools
Memory pools are pre-allocated virtual memory areas to be used at run-time for dynamically created memory resident objects. In SYS 600, there are two kinds of memory pools:
*
The global memory pool is accessed by all SYS 600 base system processes. It is used for process and report databases, execution queues, inter-process communication and so on. Local memory pools are owned and used by one process only. They contain SCIL objects (such as variables, SCIL programs and VS objects) of the process.
The pools are configured in the configuration file SYS_CONFIG.PAR, which is read at system start-up before the execution of SYS_BASCON.COM. If the SYS_CONFIG.PAR file does not exist, the default values are used. A template,
44
1MRS756112
SYS_CONFIG$PAR is copied to \sc\sys\active\sys_ during the installation of SYS 600. SYS_CONFIG.PAR can be edited with any text editor. Do not forget to remove the comment sign (;) in front of the lines. SYS_CONFIG.PAR may contain the following parameters: MEMORY_POOL_SIZE This parameter specifies the size of the global memory pool in megabytes. Recommended values are 64, 128, 192, 256 and so on. The default value is 128 (MB). The maximum possible value is slightly dependent on the operating system and the installed hardware and software. In any system, it is possible to define a 1 GB (1024 MB) pool, or a little larger. For example, the line MEMORY_POOL_SIZE = 256 sets the size of the global memory pool to 256 MB. PICO_MEMORY_POOL_SIZE This parameter specifies the size of the local memory pool of each classic monitor process in the system (process names pico, picn, pica, picv and picx). The default value is 32 (MB). REPR_MEMORY_POOL_SIZE This parameter specifies the size of the local memory pool of each report process (executing time channels, event channels and parallel queues, process name repr). The default value is 16 (MB). PRIN_MEMORY_POOL_SIZE This parameter specifies the size of the local memory pool of each printer spooler process (process name prin). The default value is 8 (MB). MEMORY_POOL_HOLE Setting this parameter causes the SYS 600 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 an external program fails to initialize and displays an error message of the following format in the Notification Window (and SYS_ERROR.LOG):
Add the following line to SYS_CONFIG.PAR and restart MicroSCADA MEMORY_POOL_HOLE = 30000000 - 301FFFFF
The line should be copied to SYS_CONFIG.PAR exactly as shown in the error message. After a restart, the program should start without errors. The configuration file can contain several MEMORY_POOL_HOLE lines, because there is a slight possibility that even the second start-up fails now suggesting another hole in the address space of the pool. The contents of the SYS_CONFIG$PAR are:
45
1MRS756112
;File: SYS_CONFIG.PAR ;Description: Configuration of static base system parameters ;Commented lines (with leading ';') show default values ;Version 9.2 SP1 ; ; ;MEMORY_POOL_SIZE = 128 ;Global memory pool (MB) ;PICO_MEMORY_POOL_SIZE = 32 ;Memory pool for classic monitor processes (pic*) ;REPR_MEMORY_POOL_SIZE = 16 ;Memory pool for report processes (repr) ;PRIN_MEMORY_POOL_SIZE = 8 ;Memory pool for printer processes (prin)
The size of the physical memory (RAM) of the computer does not affect the pool sizes in any way.
46
1MRS756112
Paging file
The memory pools are allocated from the paging file ('swap file') of the computer. The paging file usage may be calculated by the following formula: PagingFileUsage = MEMORY_POOL_SIZE + nPICO * PICO_MEMORY_POOL_SIZE + nREPR * REPR_MEMORY_POOL_SIZE + nPRIN * PRIN_MEMORY_POOL_SIZE
*
nPICO is the estimated maximum number of concurrently open classic monitors, including the ones opened by Monitor Pro. nREPR is the number of repr processes in the system. Each SYS 600 application has APL:BPQ + 2 repr processes, that is, at least two repr's plus one for each parallel queue. nPRIN equals two times the number of concurrent SYS 600 applications.
If number of concurrently open classic monitors is estimated to 10 and there is one application with 16 parallel queues in the system, the paging file usage with default SYS_CONFIG.PAR is 128 + 10*32 + 18*16 + 2*8 = 752 MB. With currently available disks, there is no need to optimize the size of the paging file to the smallest possible. It is recommended that paging file size is set to at least 4 gigabytes.
3.1.3.
Applications (APL)
The application data is stored in the SYS 600 base system computer as a directory branch under the application directory apl. For example, the application software of the local application "sample" is stored in the directory \sc\apl\sample. Fig. 3.1.3.-1 presents an example of the definition of two applications.
47
1MRS756112
The application directory branch with its subdirectories should exist before a local application can be defined in the SYS 600 base system configuration (for more information, refer to Chapter 3.1.3.3. Adding applications ).
A051602
Fig. 3.1.3.-1
Example of the fundamental definition of a base system and the definition of two local applications
3.1.3.1.
If the primary application is not defined while creating the SYS object (the attribute PA), then the application that is created first in SYS_BASCON.COM is the default application. If no application number is given while opening a classic monitor, the default application is chosen. Likewise, if no application number given when using the program interface, the default application is addressed.
3.1.3.2.
Mapping devices
Monitors, printers and stations can be mapped for an application, which means that the application recognizes the devices under logical numbers. The station mapping, for instance, specifies the station numbers under which the application recognizes the stations. The station mapping has the following format: APLn:BSTi = j
48
1MRS756112
i j
The logical station numbers as known to the application. The real STA object numbers of the stations.
The printers and stations have a default mapping, which means that each logical application recognizes them under the real object numbers. Therefore, the printer and station mapping is needed only if the application for some reason needs to know the devices under logical numbers. If there are no obstacles, let the logical numbers be the same as the object numbers (that is i = j), do not change the default values of printer and station mapping. The monitor mapping is described in Chapter 3.2. Configuring workplaces.
3.1.3.3.
Adding applications
To add a MicroSCADA application, follow the instructions given below: 1. Click Control Panel > Admin > Application to open Control MicroSCADA Applications dialog (as shown in Fig. 3.1.3.3.-1). 2. Click Add button and type in the application name with capital letters (up to 10 characters). 3. Click OK.
A070734
Fig. 3.1.3.3.-1
Adding an application
4. Depending on the usage of the application, prepare it for LIB 500 and/or for COM 500. 5. Define application characteristic in file SYS_BASCON.COM. 6. When MicroSCADA is started for the next time, application definitions are taken in use.
49
1MRS756112
3.1.3.4.
Removing applications
To remove a MicroSCADA application, follow the steps given below: 1. Stop running MicroSCADA. 2. Click Control Panel > Admin > Application to open Control MicroSCADA Applications dialog. 3. Select application from the list > Remove. 4. Confirm operation. 5. Remove application definitions from the SYS_BASCON.COM.
3.1.4.
To check the status of the current license, open License Tool and click Status button.
3.2.
Configuring workplaces
A workplace is a computer with mouse, keyboard and one or more physical monitors that have connection with MicroSCADA system. Connection to MicroSCADA system is established when user opens a monitor. The monitor can be either Classic Monitor or Monitor Pro. Workplace can be either on server computer or on remote computer. If the workplace is on remote computer, connection to server computer is established over the network by using remote client. Remote client means that programs of the workplace run on server computer, whereas graphical output and mouse/keyboard input of the processes happen on client computer. Promoted technologies between MicroSCADA server computer and remote workplace computer are Windows Remote Desktop Protocol (RDP) and Citrix Independent Computing Architecture (ICA). Two alternative software can be used for remote clients, they are Windows Terminal Server and Citrix Metaframe.
Classic Monitor
Classic monitor is a program for showing operator graphics that is implemented by using graphical resources provided by SCIL/Visual SCIL environment that is proprietary for MicroSCADA technology.
50
1MRS756112
Monitor Pro
Monitor Pro is an application that is implemented by using graphical resources provided by Windows operating system. Monitor Pro extends functionality of Classic Monitor by introducing new features for process display navigation like zooming, panning and decluttering. In addition to that, features of Windows graphical user interface are supported more widely in application frame, like menu and toolbar customization by using drag/drop, Windows standard dialogs for open, save, fonts, printing support and so on.
3.2.1.
51
1MRS756112
Terminal Server Edition. Next server products, Windows 2000 Server and Windows Server 2003 have introduced several improvements and new features. Terminal Services in Windows Server operating systems provides a new option for MicroSCADA monitor deployment. This is required to open new MicroSCADA Pro monitors from LAN connected workstations.
A070554
Fig. 3.2.1.-1
52
1MRS756112
Microsoft
Infrastructure
Customer
Clients
A070474
Fig. 3.2.1.-2
For more information, refer to the Microsoft Windows Server 2003 Terminal Server Licensing manual available in Microsofts website. Operating mode: Application Server or Remote Administration Terminal Services may be enabled in one of the two modes: Application Server or Remote Administration. Application server mode allows multiple remote clients to access Windows-based applications that run on the server. This mode should be used if many concurrent MicroSCADA Pro sessions are opened.
53
1MRS756112
Remote administration mode is designed to provide operators and administrators remote access. This feature allows you to connect to and manage a server remotely for up to two connections. Since this is designed as a single-user remote access solution, no Terminal Server Client Access License (CAL) is required to use Remote Administration. Windows XP Remote Desktop allows the same function as Windows Server 2003 Terminal Services. But there is always only one active remote desktop session at a time. If someone logs into the computer from a remote location, the local user is disconnected. Terminal Services works with client computers and terminals by using the Remote Desktop Protocol (RDP). Terminal Services Client software for Windows-based computers (RDP clients) is included in Windows Server operating systems. NonWindows-based clients require a third party add-on.
3.2.2.
x x x x
x x x x x
Transport
TCP/IP SPX, IPX, NetBEUI WAN connection Dial-up, VPN, xDSL Direct dial-up (nonRAS)
54
1MRS756112
Local printing
Local drive mapping Local drives accessible from server-based applications Local port redirection Cut and paste Redirection of server ports (LPT/COM) to local client ports Cut and paste of text and graphics between client and server Client remembers previous user's logon name for each connection Connect to an active or disconnected session using a different screen resolution. Connect directly to an application rather than to an entire desktop. Server-based applications resize and minimize similar to local applications. Application publishing Advertise serverbased applications directly to client desktops. 16-bit color depth Pooling of servers behind a single server address and for increased availability. Viewing and interacting with other client sessions (also called shadowing).
x x
x x
Remote control
55
1MRS756112
Encryption
Multiple-level encryption for security of client communications. Multiple-level encryption on Windows CE thin clients.
Administrative means for updating client connection software from the server.
Pre-configured client Predefined client with published applications, IP addresses, server names and connection options.
3.2.2.1.
A070553
Fig. 3.2.2.1.-1
Fill in the computer name or IP address of the host and click Connect. Log on to Windows dialog box by typing your user name and password.
56
1MRS756112
The Citrix client should be installed on your workstation computer to open ICA connections. It can be installed from Citrix MetaFrame installation CD or can be downloaded for free from the Citrix website.
A070710
Fig. 3.2.2.1.-2
1. Open Program Neighbourhood, as shown in Fig. 3.2.2.1.-2. 2. Create connection client. 3. Type name for the connection, add server address, set options for connection and give logon information. If no application is given, then a desktop is connected in the ICA window. You should have created user information on the server you want to log in. If you are not allowed to open client connection, check whether terminal services and licensing services are installed on server. Also check the other server side connection settings, as shown in Fig. 3.2.2.1.-3.
1. Open Terminal Services Configuration. 2. In the console tree, click Connections. 3. In the details pane, right-click the connection you want to modify, and then click Properties.
A070711
Fig. 3.2.2.1.-3
3.2.3.
WinnConn XP Server/BeTwin
Common feature for these products is to provide an alternative to Windows Server 2003 operating system as MicroSCADA Pro base system. It is possible to save in operating system costs and licenses fees especially in small systems. The following products allow multiple persons to connect and to use a single Windows XP computer from remote:
57
1MRS756112
WinConnect Server XP software (IPConsult B.V.) allows a server installed with Windows XP Pro to host up to 21 remote desktop sessions easily and cost effectively. BeTwin (ThinSoft Inc) is a software that enables two to five users to share the computing power and resources of a single computer.
All these products include their own manuals for installation and application running. One common feature with Windows Server 2003 installation is, that you should use REGISTER.EXE utility to set .DLL files available globally to the system and to all users. This utility is not included either of these two systems. For more information, refer to MMC500_TS.CMD in Installation and Administration manual.
3.2.4.
Now the value of indexes 1 ... 5 of attribute MO is -1 (APL1:BMO(1..5) = (-1,-1,-1,1,-1)), which means that monitor numbers 1 ... 5 can be opened to view application 1.
58
1MRS756112
A051606
Fig. 3.2.4.-1
Example of a workplace that is connected to two base systems and four applications
3.2.5.
59
1MRS756112
[process display] [event display] [|alarm(template) display] [blocking display]. [trends(mode) display] [reports(mode) display] -ll:x,y -ur:x,y -coordsys:world|screen -display:ulx,uly,width, height -login -loginonce -logoutonce -closeonce -loginscript -lang -light -wait
60
1MRS756112
Example FRAMEWINDOW.EXE FRAMEWINDOW.EXE FRAMEWINDOW.EXE FRAMEWINDOW.EXE FRAMEWINDOW.EXE FRAMEWINDOW.EXE FRAMEWINDOW.EXE FRAMEWINDOW.EXE FRAMEWINDOW.EXE FRAMEWINDOW.EXE FRAMEWINDOW.EXE FRAMEWINDOW.EXE FRAMEWINDOW.EXE FRAMEWINDOW.EXE FRAMEWINDOW.EXE FRAMEWINDOW.EXE FRAMEWINDOW.EXE FRAMEWINDOW.EXE C:\samplepic.v C:\samplepic.v -ll:100,400 -ur:300,500 C:\samplepic.v -display:0,0,400,400 C:\samplepic.v -light alarmlist_temp1 -loginscript C:\samplefile.bat C:\samplepic.v -loginscript C:\samplefile.bat eventlist -loginscript C:\samplefile.bat -login 510_403_1 -login demo "" 510_403_1 -login demo "" 510_403_1 C:\samplepic.v -login demo "" 510_403_1 trends_graphical my_trend_preconf -login demo "" 510_403_1 alarmlist_temp1 my_alarm_preconf -login demo "" 510_403_1 eventlist my_event_preconf -loginonce C:\samplepic.v -loginonce alarmlist_temp1 -loginonce -loginscript C:\samplefile.bat -loginonce eventlist -loginscript C:\samplefile.bat
Application Specific Application specific common process display specific menu files are in folder [Appl path]\PAR\APL\PROCESS\MENU. User Specific User specific common process display specific menu files are in folder [User path] \PROCESS\MENU. If the folder exists, the contents of application common process display specific menu folder is not investigated at all. This makes it possible, for example, to skip the application common process display specific menu files if needed by just defining an empty user specific one. Visibility Shortcut Files If visibility files have been defined, the following operations are blocked:
* * *
File open-menu item will not allow user to open any process graphics pictures. Process graphics picture drag and drop to application window is not allowed. Custom commands concerning opening process graphics displays is blocked.
Application Specific The shortcut files in [Appl path]\PAR\APL\PROCESS\TOOLBAR_SHORTCUTS are shown to all users in application process displays toolbar in Monitor Pro. If this folder is not empty (excluding user specific folders), the files in [Appl path]\PICT\ are left investigated. Other process displays than the ones in application process displays toolbar are not allowed to open.
61
1MRS756112
For backwards compatibility, the existing files in old folder are moved programmatically to new folder when Monitor Pro is started. User Specific The shortcut files in [User path]\PROCESS\TOOLBAR_SHORTCUTS\ are shown only to appropriate user, in application process displays toolbar in Monitor Pro. If this folder is not empty, the files in [Appl path]\PICT\ folder and application specific shortcut files are left investigated. Other process displays than the ones in application process displays toolbar are not allowed to open. For backwards compatibility the existing files in old folder are moved programmatically to new folder when Monitor Pro is started. Process display menu A process display menu displays both the common parts for the process pictures and the specific parts for the currently active process picture. The menu structure is similar to the Windows Start menu. The menu commands are organized as folders and files in the file system. Therefore, no special tool is needed to configure the menu. The configuration is done by organizing the files, such as programs, documents or shortcuts and the directories in a file system. For example, a menu command can be:
* * * * * *
a file a folder containing submenu commands a link a shortcut to a file a shortcut to a directory an Internet hyperlink
Defining shortcuts to process displays The user access rights can be restricted by showing the required process displays as shortcuts. The user can only open the process displays shown in a toolbar, if the shortcut files have been defined. The following operations are unavailable for the user:
* * *
Opening process displays by using the menu operation Main > Open File. Dragging process displays to an application window. Custom commands related to opening the process displays are blocked. Shortcut files should be there at the operating system level. Copying the picture is not the correct way to create the shortcuts.
62
1MRS756112
Application specific process display shortcuts are shown to all users. The shortcut files are located in Appl path]\PAR\APL\PROCESS\TOOLBAR_SHORTCUTS. The user is not allowed to open process displays that are not defined on toolbar of the application specific process displays. User specific process display shortcuts are shown individually to each user. The user specific shortcut files are located in [User path]\PROCESS \TOOLBAR_SHORTCUTS. The user is not allowed to open process displays that are not defined on the toolbar of the user specific process displays. If the user specific shortcut files exists, the application specific files are ignored.
Menu commands, which are to be shown on each shortcut menu, should be stored under the directory all. The directory objecttypes consists of all object types that a station overview can have. Menu commands that each object type can have are also located here. It is also possible that an instance of a breaker might have some menu commands that are instance specific, such as a figure of a breaker, online video stream, maintenance log or a web link to the manufacturers home page. In that case, the menu commands are located in \<unique object id>. The menu for all objects are located in <apl>\MENUS\all. SYS 600 supports two-letter language codes. When generating the menu structure, use the /culture <language> option. When the option is selected, the menu commands are displayed under the culture specific folder.
Table 3.2.5.-1
Name <apl> <object type>
For more information about <apl>\MENUS\objecttypes\ object types, refer to Section <object type>(common menu for an object type) 13.5.7. Object types in Application Design manual Name of the display file (without extension .v)
<display name>
63
1MRS756112
Menu structures are not shadowed. If a HSB system is used, the menus have to be manually copied between Hot stand-by computers after the modifications have been done. Otherwise, the directories are deleted during the switchover.
Troubleshooting
Table 3.2.5.-2
Description of the problem Only a description of a shortcut menu is displayed. A message 'No items' or the icon indicates that the shortcut menu is empty
The folder is displayed as a menu command and can be browsed. The folder does not contain submenu commands The file type of the The Open With dialog is displayed when running a menu command is unknown. The file menu command has not been associated with any program A menu command is disabled Use the Open With dialog to select the program in which you want to open the file
Check the authorization User is not authorized to run the level or the link target menu command or a link target does not exist A menu structure was not generated for the custom object type or the type does not have an SAObjectType attribute Add a menu structure manually for the custom object type and ensure that the object has an SAObjectType attribute
An instance specific menu No view was defined structure is not created for when the menu a symbol structure was generated or the symbols Object Name field is empty
Use Display Builder to set the Object Name field for the symbol. Run the menu generator and use a viewpath argument to generate menus for instances
64
1MRS756112
3.2.5.1.
OpenRemoteDesktop
This program can be used for opening a connection from workstation to active server in MicroSCADA HSB system. The workstation pings a request to detect if servers of the HSB pair are available in the network. Then it detects one of the HSB servers, which has the main application in HOT state based on APL:BAS attribute, and opens Remote Desktop connection to that server. If the applications in both HSB servers are HOT, connection is established to the server that has older timestamp (RT-attribute) in command procedure APL_INIT_H.
Installing
Installing of OpenRemoteDesktop program requires the following steps: 1. Copy executable file OPENREMOTEDESKTOP.EXE to some directory on client computer. * You can find OPENREMOTEDESKTOP.EXE file on directory \sc\prog\utils on the server computer. 2. Install OPC core components to client computer by running setup file "OPC CORE COMPONENTS 2.00 REDISTRIBUTABLE 2.00.MSI". * You can find "OPC CORE COMPONENTS 2.00 REDISTRIBUTABLE 2.00.MSI" in directory \sc\Setup\OPC_Core_Components on server computer. Client computer should have Remote Desktop client installed in it, and there should be predefined RDP session definition files on client computer for both server computers.
Remote desktop client program can be started with the following command: Start menu > Programs > Accessories > Communications > Remote Desktop Connection Configure the desktop connections and save the configurations to two different files, one for each server computer. The file extension is RDP.
Usage
Start program OPENREMOTEDESKTOP.EXE with command line switches described below: The following command line switches are required:
65
1MRS756112
IP number or node name of primary server IP number or node name of secondary server Remote Desktop Protocol (RDP) file defining session to primary server Remote Desktop Protocol (RDP) file defining session to secondary server
Example
OPENREMOTEDESKTOP.EXE -SERVER1 10.58.125.47 -SERVER2 10.58.125.48 -RDP1 c:\test1.rdp -RDP2 c:\test2.rdp -SERVER1_APP 2 The following error messages are displayed in a case when no HOT application is found in neither of the servers of HSB pair. If the server is not found in the network, that is, it does not respond to ping request, the program displays error message "Server disconnected from network". If MicroSCADA is not running, the program displays error message "Failed when making OpcServer Connect (Error: ActiveX component can't create object)", as shown in Fig. 3.2.5.1.-1. Usually this error means that MicroSCADA is not running on computer. This error message can also mean that DCOM settings of MicroSCADA OPC DA Server are not correct. It might also be that there is no valid license for running MicroSCADA OPC server, in this case the error message (for Server 1) looks like in Fig. 3.2.5.1.-2.
A071133
Fig. 3.2.5.1.-1
66
1MRS756112
A071134
Fig. 3.2.5.1.-2
If MicroSCADA application is not in HOT state, the program displays error message "Application state is not HOT'', as shown in Fig. 3.2.5.1.-3. In this case OPC connection has been successfully established to the server, and the application with given number exists in the system, and it is possible to read application attributes via OPC server.
A071135
Fig. 3.2.5.1.-3
If MicroSCADA application does not exist in the system, the program displays error message "Application does not exist in system", as shown in Fig. 3.2.5.1.-4. In this case OPC connection has been successfully established to the server, but there was no existing application with given number.
A071136
Fig. 3.2.5.1.-4
If there is a DCOM authorization problem, usually error message "Method '~' of object '~' failed" is produced, as shown in Fig. 3.2.5.1.-5. In this case, make a shortcut that launch OPENREMOTEDESKTOP.EXE as a user that has DCOM access and launch permissions to MicroSCADA OPC server on server computer. Note that same user with same password should be defined both in server and client computer or a domain user should be used to launch OPENREMOTEDESKTOP. EXE that appropriate DCOM authority on the server.
A071137
Fig. 3.2.5.1.-5
67
1MRS756112
3.2.6.
In the example there are different alarm sounds for different alarm classes. STARTALARM1.BAT starts alarm sound for alarm class 1. Its contents could be the same as following:
cd d:\wav PlayAlarm.exe AlarmClass1.wav 2000
Programs PSEXEC.EXE and PLAYALARM.EXE are delivered on request by MicroSCADA product support.
68
1MRS756112
3.3.
Configuring communication system objects in base system Configuring process communication units (PC-NET, External OPC DA Client, CPI applications)
In general, the process communication units cannot be created or accessed from any application before the corresponding system objects in base system has been configured. The definition method of these system objects depends on used process communication unit type. The required base system object types are as following:
*
* *
LINn:B object which defines a communication route from the base system to the defined node NODn:B object which in this context defines the node of process communication unit itself STAn:B object which defines a station within a defined node PRIn:B object which defines a printer within a defined node
If the used process communication unit is of type PC-NET and System Configuration Tool is used, these base system objects are created automatically. If the System Configuration Tool is not used or the used process communication units are other than PC-NET, refer to Section 3.3.2.2. - Section 3.3.2.5. or to PC-NET start-up with SCIL commands in Section 3.3.2.1. Configuring PC-NET. System Configuration Tool supports only process communication units of type PC-NET. These objects can be also be configured using SYS_BASCON.COM as described in Section 3.1.2. Base system (SYS) or with SCIL using statement #CREATE.
3.3.1.
69
1MRS756112
One link of type LAN. The process communication unit may be directly connected through LAN link. The LAN link is used between base systems and the process communication unit may be connected to another base system (indirect connection). The definition of LAN links is described in Section 3.8.2. Communicating between applications. One link of type INTEGRATED for each configured PC-NET. This link type is used only by PC-NET process communication unit and it is created by the System Configuration Tool. The PC-NET.EXE process is started when the LIN: B object of type INTEGRATED is created.
Node (NOD) Nodes are directly or indirectly connected base systems and process communication units. The nodes are defined by NODn:B objects (n = 1 ... 250). A node definition is needed for:
*
Communication to the communication units. Each process communication unit which is recognized by the base system must be defined as a node. These node definitions are described in System Objects manual. Reading and writing attributes. A node is primarily specified by the used connection link and the station address of the node. If a node is only indirectly connected to the base system, the link to the node is the link to the nearest intermediate node. The link object must have been defined before the node can be defined.
Node definition is also used to define another base system in a network. This is described in Section 3.8.2. Communicating between applications. Example: A process communication unit uses LAN link and is configured to be node 3 and its address is 203. The first step in the configuration is to create a LIN:B object of type LAN (if not yet created for the base system communication).In this situation, the link number can be selected. The next step is to create NOD3:B object for the process communication unit and assign selected link number to the NOD3:BLI attribute of the created object. The node address 203 is assigned to the attribute NOD3:BSA. This configuration must be present before the process communication unit in node 3 can be accessed. For more information, on system objects of type NOD and LIN, refer to System Objects manual. The process communication unit is PC-NET and System Configuration Tool is used, these base system objects are created automatically, otherwise the NOD and LIN need to be created with SCIL. The example above would then require the following lines:
; L I N 1:B O B J E C T # C R E A T E L I N : V = L I S T (L T = L A N , T R = T C P I P ) #CREATE LIN1:B=%LIN ;NOD3:B OBJECT # C R E A T E N O D : V = L I S T (L I = 1 , S A = 2 0 3)
70
1MRS756112
3.3.2.
PC-NET External OPC DA Client CDC-II slave Modbus slave Other CPI-connected applications
Most of the communication protocols are supported by the PC-NET process communication unit. For more information on attribute PO and a complete list of protocols, refer to the System Objects manual. Communication unit of type External OPC DA client is used with OPC connected protocols such as IEC61850. External OPC DA client, CDC-II slave, Modbus slave and other CPI-connected applications. LAN link is used as the communication route between base system and the communication unit.
3.3.2.1.
Configuring PC-NET
The recommended way to configure process communication unit of type PC-NET is to use System Configuration Tool. While creating the full configuration, it provides a set of possible selections in each step. In practice, these selections are mainly protocol specific line type and station types. The usage of the System Configuration Tool is described in Chapter 4. Configuration tools. It is also possible not to use the System Configuration Tool and create the line and station configuration using SCIL. The protocol specific manuals contain examples of how this is done with each protocol. This method is often used when a MicroSCADA system is updated to a newer release and the amount of changes to the system is tried to minimize. When the PC-NET program is started, it reads the initial configuration file PC_NET. CF1, which is a text file located in the \sc\sys\active\sys_ directory. It defines the basic communication nodes and addresses to enable the communication to an application that downloads the total configuration. When a PC-NET configuration is created with the System Configuration Tool, the tool produces two data files: SYSCONF.INI and SIGNALS.INI. When the system is started, it reads the mentioned files and creates a file PC_NET.CF1 automatically. To create system objects, the System Configuration Tool automatically creates the file SYS_BASE.SCL, which is executed at system start-up. After the PC-NET has started, the system executes the file SYS_NET.SCL to configure the PC-NET. The file is automatically created by the System Configuration Tool. A step-by-step description of the System Configuration Tool operation is described in Section, PCNET Startup with System Configuration Tool. This information is rarely needed, and in practise the system configuration can be entered and controlled without knowledge of the internal operation of the tool.
71
1MRS756112
In case the PC_NET.CF1 file is missing when the PC-NET is started, a default configuration becomes valid.
A command procedure SYS_INIT_1:C is connected to the event channel APL_INIT_1:A as the first secondary object. If the list of the secondary objects is full, the last one is removed and a warning is generated (notify window, log file). The command procedure SYS_INIT_1:C calls a text file (StartPC-NET.SCL) which starts the PC-NET. The program in the text file first updates the sys_/ PC_NET.CF1 file and then starts the PC-NET by setting the corresponding base system link object type to INTEGRATED. The PC_NET.CF1 file is updated in the following way:
The PC-NET sends a system message to the own application when it is started. This message is received by a process object to which an event channel, SYS_NET'net_number'D:A, is connected. This event channel calls a command procedure SYS_NET'net_number'D:C. If the process object exists (for example created by LIB5xx) and has an event channel connected to it, all the objects connected to that event channel is moved to the SYS_NET'net_number'D:A event channel as secondary objects. In other cases, the System Configuration Tool automatically creates a process object SYS_NETD:P('net_number'), to which the event channel SYS_NET'net_number'D:A is connected. The command procedure SYS_NET'net_number'D:C checks the message coming from the PC-NET. If this is the start message (10001), the PC-NET is configured according to the information entered in the System Configuration Tool.
72
1MRS756112
If the system configuration contains many PC-NETs, then for each of the PC-NET processes to be started by System Configuration Tool, an instance specific copy of PC_NET.CF1 file can be found from the same folder. These files follow the file naming convention DEBUG'net_instance_number'.CF1, for example, file name DEBUG1.CF1 is used for the first PC-NET process instance. All the possible error messages that occur during the start-up or configuration of the PC-NET are shown in the notify window. They are logged into the SYS_ERROR. LOG and SYS_ERROR.OLD log files, which can be viewed using some text editor of Windows operating system.
When a PC-NET unit is restarted, it sends the system message 10001 to all the defined applications (by default to process object address 6000 + NET no), provided that the application is running. The system message can be used for updating a process object which activates an event channel, which in turn starts a command procedure with reconfiguration commands. For more information describing the System messages from PC-NET units, refer to System messages base system configuration and System Messages - PC-NET configuration described later in this section. When the connection between PC-NET and an application recovers after a break, PC-NET sends the system message 1000 + APL no. to the application (by default to address 6050 + NET no.). This message can be used for conditional start of reconfiguration procedures, that is, reconfiguration takes place if PC-NET has been restarted, not if the application has been out of use. This can be checked for example by reading a system object attribute configured online. If online configuration changes are valid, PC-NET has not been out of operation.
Reconfiguration commands could also, for example, be included in the command procedures started by the event channels APL_INIT_1 and APL_INIT_2, (APL_INIT_H in hot stand-by systems, refer to the Application Objects manual). However, a PC-NET unit can be restarted even though the application is not restarted. The protocol specific manuals contains examples for the configuration script for each protocol. In principle, following step are needed for every protocol: 1. Define the NET line to be used by assigning it the wanted protocol. 2. Give the line its communication properties by means of the line attributes. 3. Create the station(s) by giving it an object number and assigning it the line number. 4. Set the attributes of the created object. 5. Take the line and the device into use.
73
1MRS756112
In SCIL, communication system objects are created and deleted using NET attributes, refer to the System Objects manual. When adding a device, the NET line should first be defined. NET lines are defined by the NET line attribute PO. The used hardware device is generally defined with attribute SD, which, for example, may refer to certain serial port or PCLTA card.
74
1MRS756112
OBJ in this context may be STA referring to a station object or PRI referring to a printer object. For more detailed information about the object notation, refer to the System Objects manual. The attributes are written with the #SET command according to the format:
#SET OBJnn:SATi = value
The line attributes can be changed with the SCIL command #SET:
#SET NETnn:Sati = value 'i' Line number
For detailed information on each attribute, refer to the System Objects manual or protocol specific configuration manuals.
75
1MRS756112
The default values of MI attributes for each station type are presented in the System Objects manual and in the protocol specific manuals. The defaults listed below are protocol independent:
Table 3.3.2.1.-2
Object NET itself
Message General messages, for example start-up messages Value: status code
6050 + NET no. Application supervision Value: APL no.= failure 1000 + APL no. = recovery (APL no. as known to NET) NET line All NET line messages 6000 + 100 NET no. + line no.
3.3.2.2.
76
1MRS756112
MicroSCADA network. In other words, the related base system objects has to be created in the SYS_BASCON.COM file and the OPC namespace of the IEC 61850 OPC Server has to be mapped into process objects. The required station type for units is "SPA". The mapping between OPC items and process objects is done in External OPC DA Client Configuration Tool. For description of the different topologies and configuration details of this IEC 61850 communication, refer to IEC 61850 System Design manual. Otherwise, the configuration of External OPC DA Client has been described in the External OPC Data Access Client manual and IEC 61850 Server in the IEC 61850 Master Protocol OPC manual.
3.3.2.3.
3.3.2.4.
3.3.2.5.
77
1MRS756112
3.3.2.6.
Selected configuration examples for PC-NET Base system network using serial ACP
For performance reasons, generally there should not be more than three communication units in a series between a base system and a communicating device. These are base system, workplace, printer or RTU. When communication units and base systems are connected to a network, each NET unit and each base system in the network should be defined as a node in each others NET unit and base system. In order to connect two communication units through serial lines make the following definitions in each of the unit: 1. Select a line for the connection and define it with the ACP protocol as follows:
PO MS MI BR PY SB RD TD ER RE TI NA EN PS 1 System message application System message object address Baud rate Parity Number of stop bits Read data bits Transmission data bits Embedded response Redundancy Time-out length in seconds (1 + 2400/BR) NAK limit ENQ limit Buffer pool size
The communication attributes (BR, and so on) 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 Device number LI, Line number SA NOD The node number of the connected communication unit The number of the selected line Station address of the connected communication unit
78
1MRS756112
Though two communication units are connected indirectly via another unit, they should be defined to each other. Make the following definitions in each of the units. 3. Define an "External node" (NET object) connected to the line to the nearest communication unit:
Device type Device number LI, Line number SA OD The node number of the indirectly connected communication unit The line to the nearest NET unit in the series Station address of the indirectly connected communication unit
Each NET unit which is connected to a base system via one or more other units should be defined to the base system as a node (NODn:B objects): 1. Create a NODn:B base system object corresponding to the indirectly connected communication unit. The NOD object number ('n') should be the same as the node number of the communication unit. The NOD object is given the following attribute values:
LI SA Link number (= LIN object number) This is the link to the nearest communication unit Station address of the indirectly connected communication units
Even if there is no communication between the base system and the indirectly connected NET, the node definition is necessary for the system diagnostics, online configuration and system maintenance. 2. Define an "External node" (NET object) on the line to the nearest communication unit:
Device type NOD Device number LI, Line number SA The node number of the indirectly connected base system The line to the nearest communication unit in the series Station address of the indirectly connected base system
3. Define an application for each application in the indirectly connected base system. Fig. 3.3.2.6.-1 shows an example of a network of two communicating NETs and two base systems. The table below shows the configuration of the NETs and base systems. The example includes only the definitions which are of importance for this particular configuration and which have not been described in the previous sections.
79
1MRS756112
Link 1
Base System 1
Node Number: 9 Station Address: 209
Communication frontend
Node Number: 6 Station Address: 206 Communication Unit 1 Communication Unit 2 Node Number: 2 Node Number: 1 Station Address: 201 Station Address: 202 Serial lines
Apl1
12345678
12345678
Base System 3
Node Number: 11 Station Address: 211 Communication Unit 3 Node Number: 3 Station Address: 203 Serial lines
Apl5
12345678
Basys_Nets_Frontends2.eps
A051805
Fig. 3.3.2.6.-1
See Fig. 3.3.2.6.-1.
Configuration of Communication unit 1 External node 9 (Base system 1) Device type: Device number: LI IU SA Application 1 Line number: In use: Station addr. (Dec.): Device type: Device number: Translated APL number: Node number: IU SW In use: Reply timeout: NOD 9 13 1 209 APL 1 1 9 1 5 60
Suspension time: SU Configuration of Communication unit 2 See Fig. 3.3.2.6.-1. Line 2 (ACP line) PO IU MS MI LT BR Protocol: In use: Message application: Message ident: Link type: Baud rate:
1 1 1 6202 1 9600
80
1MRS756112
Buffer pool size: PS External node 3 (Communication unit 3) Device type: Device number: LI IU Line number: In use:
Station addr. (Dec.): SA External node 9 (Base system 1) Device type: Device number: LI IU Line number: In use:
Station addr. (Dec.): SA External node 11 (Base system 3) Device type: Device number: LI IU SA Application 1 Line number: In use: Station addr. (Dec.): Device type: Device number: Translated APL number: Node number: IU SW SU Application 5 In use: Reply timeout: Suspension time: Device type: Device number: Translated APL number: Node number: IU SW In use: Reply timeout:
81
1MRS756112
Buffer pool size: PS External node 2 (Communication unit 2) Device type: Device number: LI IU Line number: In use: Station addr. (Dec.): Device type: Device number: LI IU SA Application 1 Line number: In use: Station addr. (Dec.): Device type: Device number: Translated APL number: Node number: IU SW SU Application 5 In use: Reply timeout: Suspension time: Device type: Device number: Translated APL number: Node number:
82
1MRS756112
1 5 60
For more information on the attributes, refer to the System Objects manual. The STAn:B object definition is not necessary, if the default station type defined by SYS:BDS is RTU and the default node defined by SYS:BDN is the NET unit to which the RTU is connected and the mapping is direct. However, if no STAn:B object is defined, the station cannot be handled by the MicroSCADA Pro tool pictures. 2. If needed, map the station for the application which uses it with the APLn:BST attribute. Station mapping is necessary only if the logical number is another than the STAn:B object number, which is the default mapping. The logical station number is the Unit Number (the UN attribute) of the process objects defined for the station. For more information, refer to the System Objects manual. PC-NET configuration Perform the configuration definitions described below in the NET unit to which the station is directly connected. It is assumed that the NET unit has been defined to the base system as a NODn:B object, and that the base system has been defined to the NET unit as an external node. 1. Select a line for the station (several RTUs can be connected to the same line) and define it with the RP 570 protocol:
PO LT IU MS MI BR PY RD 7 0 (RS232) or 1 (modem line) 1 The application receiving system messages The object receiving system messages Baud rate, should be the same as in the RTU 2 8
83
1MRS756112
Timeout in milliseconds for start of response reception (default = 700 ms) Time delay in milliseconds before enabling a line after a message. Default = 0. A time delay should be used, if NET's transmission echoes back into the receiver. RTS keep up padding characters, refer to the System Objects manual
RI
RK
2. Make sure that the application which receives spontaneous messages from the station (the station attribute AS) is defined as an APL object. 3. Define a station of type RTU connected to the RP 570 line:
Device type LI AL AS MS MI SA RT Selected line number 1 The number of the connected application The application receiving system message The object receiving system messages RP570 station address (= the address in the RTU) Reply timeout in seconds 4
If several stations are connected to the same line, define the stations with the same line number (LI). The NET unit recognizes an automatically created "station", STA0, as "broadcast station". The broadcast station notates all S.P.I.D.E.R. RTUs connected to the same NET. 4. Synchronize the RTU200 clock with the clock of the NET unit at start-up by setting the SY attribute, for example, #SET STAn:SSY (supposing that the NET clock has been synchronized before). By using the broadcast station number, all RTUs connected to one NET can be synchronized simultaneously. 5. If needed, change the AW attribute of the RP 570 line (refer to the System Objects manual). This is normally not necessary. A SYS 600 revision beginning with 8.2B supports the configuration of hierarchical RTU structures. Define the sub-RTUs as STA objects in NET and in the base system, in the same way as an RTU connected directly to NET as described in the manual. The only difference between the directly connected RTUs and sub-RTUs is the STAn:SHR attribute, refer to the System Objects manual. For STA objects corresponding to sub-RTUs, the HR attribute is the station address of the RTU one level above in the hierarchy.
84
1MRS756112
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: byte 5 : bytes 6..7: bytes 8..9: byte 10: byte 11: VALUE (least significant byte first) STATUS with time quality and so on, copied from RP 570 telegram RELATIVE TIME (least significant byte first) NUMBER (least significant byte first) CAUSE OF TRANSMISSION FORMAT
The coding of each field, when not explicitly described above, follows the RP 570 telegram. There are two methods of building an RTU configuration. The RTU configuration can be performed independently of SYS 600, which means, the SYS 600 process object definition is built separately with no help from the RTU configuration files. Alternatively, the RTU configuration can be built via SYS 600, which means, the SYS 600 engineer can use the configuration in the process object definitions. Changes in the SYS 600 process database can then be loaded down to the RTUs. RTU configuration It is recommended to build the RTU configuration via MicroSCADA Pro. For this, the following steps are required :
85
1MRS756112
Using the EDU (Engineering and Diagnostic Unit) tool, that is the RTU configuration tool for RTU engineering. The RTU configuration is stored in key files. When using EDU, a file conversion is required. Defining the process database objects in the MicroSCADA Pro system using the key files. Loading down the complete configuration to the RTU, including possible changes made in the SYS 600 process database.
Loading the RTU configuration If your RTU is connected, you can now load the configuration, or you can use the process definition tool to make changes in the definitions. To do this, select Other Choices > Download > Start.
The STAn:B object definition is not necessary if the default station type, defined by SYS:BDS, is STA and the default node, defined by SYS:BDN, is the NET unit to which the station is connected to and if the mapping is direct. If needed, map the station to the application which uses it with the APLn:BST attribute. Station mapping is necessary only if the logical number is other than the STAn:B object number, which is the default mapping. The logical station number is the Unit Number (the UN attribute) of the process objects defined for the station (refer to the System Objects manual). Configuration for SRIO device SRIO system parameters By changing the SRIO 1000M system parameter values, the application programmer can affect general features of the SRIO 1000M program. The system parameters are located in the address area from 3000 upwards. Table 3.3.2.6.-1 shows some examples of system parameters, each of which occupies one word. For further information about SRIO system parameters, refer to the SRIO manuals.
86
1MRS756112
Table 3.3.2.6.-1
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)
Example:
#SET STA1:SME3001=0
Analog values to be coded as 3-digit BCD numbers. SRIO object parameters The SRIO object parameters allow the MicroSCADA Pro applications to read and write the definitions of data items, data groups and event data polling. The start address of object parameters is 5000 in the default configuration. SRIO can contain up to 500 objects. The following attributes are defined for each data item (start address refers to the start address within the object parameter area, that is add 5000 to each address):
Attributes ANSI address Bus number SPACOM address Data type/format Delta value/bit mask (32 bits) Status word (16 bits) Start address 0 500 1500 4500 5500 6500
87
1MRS756112
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 @DATA_T_F(2) = %DFORM #SET STA1:SME (%D_T_F_ADR..(%D_T_F_ADR + 1))=%DATA_T_F (1..2) @DELTA_S_A = %DELTA_I + 2 * %OBJ_IND ;32-BIT ADDRESS #SET STA1:SME (%DELTA_S_A) = %DELTA #SET STA1:SME (%STATUS_I+%OBJ_IND) = %STATUS
A data group can consist of 10 data items, and there can be up to 100 data groups. The data group definition tells the ordinal numbers of the data items in the group. The data group definitions are found from the address (7000 + object parameter area start address). Above is an example of a SCIL command procedure which defines a data group. The event data polling can cotain up to 300 SPA bus slave units (100 slaves/bus). In the address range starting from 8000 + object parameter area start address. The following features of each object to be event polled are defined:
* * * *
Defining constants
@GROUPDEFSA = 12000 @GROUPLEN = 10
1MRS756112
ANSI X3.28 Half Duplex or Full Duplex protocols, ACP (Application Communication Protocol) Modbus Alpha IEC 61107 RP 570 master and slave SPA IEC 60870-5-101 master and slave IEC 60870-5-103 master DNP 3.0 master and slave
The example below describes the configuration using SCIL. The usage of the System Configuration Tool is possible and recommended. Auto-dialling is useful for the following reasons:
* * *
For the connection of remote stations with infrequent data transfer For the connection of home terminals For taking a reserve line into use
Auto-dialling is possible in both directions. The auto-dialling line can be defined in the preconfiguration. However, the autodialling feature cannot be preconfigured, it should be configured and taken into use online. Create the line in the preconfiguration or online. Depending on the device(s) connected to the line, set the Protocol (PO) attribute to 1 for the ANSI X3.28 Full Duplex protocol, 2 for the ANSI X3.28 Half Duplex protocol, 25 for Modbus RTU mode master protocol and 26 for the IEC 61107 protocol. The auto-dialling feature for a line can be added by using a tool or SCIL. The dialup modem has to be connected to the line while defining the auto-dialling feature. To define the auto-dialling with SCIL: 1. Take the line out of use by setting the In Use (IU) attribute of the line to 0, for example: #SET NET1:SIU5 = 0 2. Set the ACE (AC) attribute of the line to 1, for example: #SET NET1:SAC5 = 1
89
1MRS756112
3. If the NET unit is supposed to answer incoming calls which is always the case on RP 570 lines, set the Remote Calls Enabled (RC) attribute to 1, for example: #SET NET1:SRC5 = 1 4. If an automatic break of the connection is wanted after a specified time, set the Connection Time Limited (CL) and Connection Time (CT) attributes, for example: #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. Refer to the System Objects manual. 6. Set the In Use (IU) attribute of the line to 1, for example: #SET NET1:SIU5 = 1 To dial up a workplace or RTU from a NET: Set the Connection (CN) attribute in an application program as follows: #SET NETn:SCNline = "phone" or when dialling a station: #SET NETn:SCNline = "phoneSstation" where
line phone station Line number Phone number of the receiver Station number of the receiver
Dialling is done while the line is in use (IU = 1). When the NET is dialling, system messages with codes 16107, 16208 or 16825 (depending on the protocol) are generated. If a station is dialling, the codes 16108, 16209 or 16826 are generated. A failed dial-up generates the code 16704. The connection to an RTU is broken automatically, under the following circumstances:
* * * *
RTU becomes inoperable RTU hangs up when the RTU is the dialling part RTU has nothing to send (after two subsequent CCR2 responses)
90
1MRS756112
In addition to these, the connection can be broken automatically according to the Connection Time (CT) attribute. If the connection is not broken automatically, break it by setting the Connection (CN) attribute to 0: #SET NETn:SCNline = 0 A succeeded hang-up generates a system message with code 16733. If the hang-up failed, the code 16702 or 16703 is generated. The status codes 16106, 16107 and 16810 indicate that disconnection has started. Example: Dialling a MicroTERMINAL: #SET NET1:SCN5 = "1234567" Dialling station 11 (STA11): #SET NET1:SCN5 = "1234567S11" Breaking the connection: #SET NET1:SCN5 = ""
3.3.3.
91
1MRS756112
3.3.3.1.
Distributed PC-NETs
There are many reasons why it is necessary to divide the PC-NETs to operate in a separate computer or multiple separate computers:
* * * *
Computer hardware limitations of LON or serial cards Decreasing the problems caused by a computer failure Process communication causes CPU load Redundancy is required in the process communication level
The base system which is directly connected to the PC-NET usually contains no process database. Fig. 3.3.3.1.-1 presents the system containing a hot stand-by base system containing a process database and three separate computers for process communication. In the system, the CPU load caused by the process communication is divided to three CPUs. Furthermore, if a hardware failure occurs in some of the computers, the rest of the system is still under control.
Process database HSB SYS MAIN APL1 WD APL2 SYS21 APL11 NET 1 SYS22 APL12 NET 2
LAN
STA10..STA40
Fig. 3.3.3.1.-1
STA50..STA80
STA90..STA120
A070472
PC-NET configuration
The communication front-end base systems SYS21..SYS23 running APL11..APL13 only routes the ACP messages between PC-NET nodes and APL1. In the system start-up or in the hot stand-by switch the APL1 is defined to be in either of the base systems containing the database. Fig. 3.3.3.1.-1 describes a situation, in which there is only one PC-NET running in each computer. In practice, each of these computers may contain multiple PC-NET instances and various set of lines using different protocols. Furthermore, each of these computed may also be doubled using hot stand-by configuration. The watchdog APL object needed in hot stand-by configuration is APL2.
92
1MRS756112
At the process database level, the system may also contain mirroring. For more information about hot stand-by redundancy and mirroring issues, refer to Section 3.9.1. Hot stand-by base systems and Section 3.10. Configuring mirroring. The System Configuration Tool should be used in each of the computers running the PC-NETs. The configuration in the base system running APL 11 could be the same as presented in Fig. 3.3.3.1.-2.
A071293
Fig. 3.3.3.1.-2
The corresponding STAn:B objects should be configured to the base systems containing the process database. The selected part from the SYS_BASCON.HSB file (described in Section 3.9. Configuring redundancy) for the system described above would be:
. . @BS_NODES = (9,10, 21, 22, 23) ;BASE SYSTEM NODES @FE_NODES = (1,2,3) ;FRONT-END NODES @FE_NODE_LINKS = (1,1,1) ;LINK NUMBER OF FE NODES . . ;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 NODNODE: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 NODNODE:B = %NOD #LOOP_END ;BS_NOD_END
93
1MRS756112
The definition file above will create NOD:B objects for base systems and PC-NET nodes. After this, the STAn:B objects are created for each station object created to the PC-NET nodes. This configuration should match with the configurations entered with System Configuration Tool. When a hot stand-by switch, that is, take-over occurs during run-time, the main application changes to HOT state in the adjacent base system. In this situation, a procedure SHADMAPNET is executed and PC-NET nodes are informed that the application is running in another base system node. The used attribute is NET node attribute SY. For more information about the hot stand-by configuration and the runtime operation, refer to Section 3.9.1. Hot stand-by base systems.
3.4.
94
1MRS756112
system supervision picture updated, when configured accordingly. Beyond the process objects, it is MicroSCADA base system and communication engines that mainly provide the means for the different supervision events. Before any process object has its own supervision logic, there is need to do the application engineering by using application objects of SYS 600. In other words, by using the event channels, time channels and command procedures the logic for supervision information will be introduced into application. While introducing the supervision logic in application, follow the design considerations given below: 1. Keep the supervision logic for each component as simple as possible. Introducing more application objects into the re-processing chain of the same supervision event means that there will be delays and the granularity of the operation will be split to several places. 2. Represent the status information in binary way - one value representing the good status, and another value representing the bad status. In the SYS 600 process database, use process objects of type Binary Input for this. Use naming convention for the supervision process objects, as it is easier to recognize them among the other application process objects. 3. When detailed information is needed for certain system component, include detailed pictures or displays providing the detailed information on request. 4. Use Windows operating system events by using OS_EVENT predefined event channel and re-route the information into the process objects. 5. If system contains the devices capable for sending the SNMP messages in SYS 600 network, use SNMP-OPC gateway solution. It helps you to map the supervision information into process objects by using the subscription of related OPC items from the SNMP-OPC Server namespace. 6. When engineering system supervision picture, try to re-use the symbols found from the Palette of SYS 600 Display Builder. Include the color semantics representing the status information either beside the symbol or inside the symbol, when feasible.
3.4.1.
95
1MRS756112
In some cases, some time channel based activations may be required. An example of the command procedure to be attached into time channel to supervise the PC-NET communication engine.
@i_Timeout = timeout(1000) #error ignore @i_Status = status @i_IU = NOD3:SSA #error stop @i_Timeout = timeout(%i_Timeout) #if status == 0 #then #set SYS_N0003:POV10 = 0 #else #set SYS_N0003:POV10 = 1
3.4.2.
When configured in the above way, the corresponding binary status object has an address Message Identification (MI) + 16 777 216 (MI + 1 000 000 hex). The purpose of the received value into binary process object is to indicate, whether the communication line, station object or the NET node is OK (value 1) or not OK (value 0). For more information about the binary objects with system message from PC-NET, refer to the System Objects manual. The related attributes are MI and MS. For the IEC 61850 systems, use the following approach. When stations are connected to the SYS 600 system through IEC 61850 OPC Server, the process objects mapped to the Device connection status OPC Item per IED should be used. Use the OPC Item IEC61850 Subnetwork\AA1CP2\Attributes\Device connection status to update the process object SYS_S0001:P10.
3.4.3.
96
1MRS756112
Table 3.4.3.-1
Functionality Base System
Monitor
MONITOR.SD
Communication Line
DECREASE.SD
97 International 01 SA_Common
Station
IED.SD
91 Computers
3.4.4.
A071123
Fig. 3.4.4.-1
Alternatively, if there is no suitable area inside the supervision symbol that could be used for dynamics, it is proposed to use rectangle or circle, beside the symbol. In Fig. 3.4.4.-2, the static symbol has been adjusted with the Rectangle object including dynamics.
A071124
Fig. 3.4.4.-2
97
1MRS756112
3.5.
A070466
Fig. 3.5.-1
A070467
Fig. 3.5.-2
3.5.1.
SYS_BASCON.COM modifications
Command procedures of COM 500i use parallel queues and comment marks (-; characters) should be removed from the beginning of PQ and QD attribute lines in SYS_BASCON.COM file. Application definition for gateway:
#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 = 16,;Number of parallel queues/ Needed in COM500 Applications QD = (1,1,0,0,0,0,1,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
98
1MRS756112
3.5.2.
Gateway license
The gateway functionality can be used, if the value in the gateway field is non zero. The value also tells, how many NCC lines can be configured in the Signal XReference Tool.
Fig. 3.5.2.-1
Gateway license
3.6.
Printers I/O cards (Adaptech 1760, Nudaq 7250 and 7256) Meinberg clock cards
3.6.1.
Configuring printers
To connect a printer directly to a base system computer, follow the instructions given below: 1. Connect the printer to a parallel or serial port. Printers connected to the parallel port of a base system computer can be placed at a maximum 3 metres from the base system computer. Serial lines allow the connection lines to be up to 15 meters without modem. 2. Configure the printer to the operating system as described in the Windows manuals. Define the printer as shared if it is going to be used by several base systems or other Windows computers on the LAN. 3. Select the connection mode on the printer. * Select parallel mode if the printer is connected to the parallel port. * Select serial mode if it is connected to a serial port. 4. Configure the printer in the base system as a PRIn:B object. If the printer is used by several base systems, or by programs other than MicroSCADA Pro on the same or other computers, set the printer's OJ attribute to 1. Printers, that is used by several base systems, should be defined in all base systems, both regarding the operating system configuration and the MicroSCADA Pro configuration.
3.6.1.1.
LAN connection
Printers connected to a base system computer or LAN should be configured in all base systems that will use the printers.
99
1MRS756112
3.6.1.2.
NET connection
A printer connected to a PC-NET communication unit can be used by all base systems connected to the same network. The printer should be defined both in the base systems, which uses it and in the PC-NET unit to which it is directly connected, as shown in Fig. 3.6.1.2.-1 . It is assumed that the PC-NET unit has been defined to the base system as a NODn:B object. Include the following definitions in each base system which will use the printer: 1. Create a PRIn:B base system object with at least the following attributes:
TT ND TN DT LOCAL The node number of the NET unit to which the printer is directly connected The device number of the printer in the NET unit to which it is directly connected "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. NET
DC
For more information on the attributes of the PRI object, refer to the System Objects manual. 2. If needed, map the printer for an application with the APLn:BPR attribute. The printer mapping is required only if you want to use a logical printer number which is not the same as the printer object number. Only the printers mapped with the logical printer numbers 1 ... 15 can be used as alarm and event printers; printer 15 is reserved for event lists.
Include the following definitions in the NET unit to which the printer is directly connected:
100
1MRS756112
Base System 1
Node Number 9 Station Address 209 Link 1 = Integrated link Line 13 = Integrated link Communication Unit 3 Node Number: 3 Station address: 203 Apl 1
Base System 2
Node Number 10 Station Address 210 Apl 2
Printer 1
PRI 1
1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
Configuration of NET3 Line 1 Base system configuration (in both base systems) Node : see chapter 3 Printer 1 #CREATE PRI:V #SET PRI:VDC=NET #SET PRI:VDI=COLOR #SET PRI:VND=3 #SET PRI:VTN=1 #SET PRI:VTT=LOCAL #CREATE PRI1:B = %PRI PO Protocol: IU In Use: MS Message Application: MI Message Identification: BR Baud Rate: SB Stop Bits: PY Parity: RD Receiver Data Bits: TD Transmit Data Bits: OS Output Synchronization PS Buffer Pool Size Printer 1 LI Line number AL Allocation AS Allocating application IU In Use MI Message Identification MS Message Application PT Printer Type 4 1 1 6101 2400 1 0 8 8 3 15 1 0 0 1 3001 1 5
A070475
Fig. 3.6.1.2.-1
1. Select a line for the printer and define the line with the ASCII protocol:
PO IU LT MS, MI PS BR PY RD SB TD OS 4 1 0 System message handling, see Chapter 17. Buffer pool sizes, see Baud rate (recommended value 2400) 0 8 1 8 Output synchronization, refer to the System Objects manual, Chapter 13
2. Define a printer (a PRI object) on the selected printer line with the attributes:
101
1MRS756112
LI IU MI, MS AL, AS PT
The number of the selected line 1 System message handling 0 (the printer reservation is handled automatically by the base system 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, refer to the System Objects manual. The three attributes mentioned can be found in the System Objects manual. 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.
3.6.2.
102
1MRS756112
Table 3.6.2.-1
1 2 3 4 5 6 7 8 9
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
103
1MRS756112
A070714
Fig. 3.6.2.-1
For more information about the Advantech PCI-1760 and ADLink PCI-7250 and PCI7256 I/O driver installation and configuration, refer to the respective card manufacturer documentation. The Windows drivers for PCI cards are delivered with the cards. The driver versions supported by MicroSCADA Pro are:
* *
Version 2.0 of the ADLinks PCI-7250 I/O card driver for Windows. Version 1.10 of the Advantechs PCI-1760 I/O card driver for Windows.
The supported versions of the drivers are available in the following websites:
* *
3.7.
104
1MRS756112
LON line or using an external application. When the SYS 600 system is operating as a communication gateway, the synchronization is often received from the network control center through the used communication line. If IEC 61850 communication server is used in MicroSCADA PC, SNTP time synchronization can be used. The same internal clock is used, when the real IEDs connected to the SYS 600 system are synchronized through the communication lines in process communication units. In most of the communication protocols there is a predefined method to synchronize the IED. For more information about the synchronizing methods, refer to the protocol specific manuals. When SYS 600 is used to synchronize the IED, the synchronization command is usually initiated cyclically from the application running in the base system. The related station object attribute is SY for many protocols. In some protocols, there is a possibility for the IED to request a time synchronization from the master. The process communication units running in the same computer use the same system clock, which means, there is no need to make separate synchronization for the unit. This is different from the DCP-NET units used with the older SYS base system versions, where the units had a separate clock in the used hardware. When operating as a communication gateway, the network control center may operate in a different time zone. The corresponding compensation attribute is TZ which exists both in SYS:B object and NET:S object (only for process communication unit PC-NET).
3.7.1.
In step 2, it is defined if the clock of the SYS 600 computer is synchronized from an external source. This source could be a network control center or a radio clock device connected to a communication line in PC-NET, an external application using SNTP server and/or GPS device, a SLCM-card connected to LON star coupler and so on.
105
1MRS756112
If the source of the time is connected to communication line of the PC-NET, some configurations tasks may be required. For IEC60870-5-101/104 and DNP3.0 protocols, refer to corresponding slave protocol manuals, station attribute TC. For LON protocol, refer to System Objects manual. The time zone compensation is done with attribute SYS:BTZ. If the source of the time is an external application or a special device, refer to the corresponding manuals for more information. In step 3, the requirements of the used IEDs are defined. These requirements may define the minimum frequency of the incoming time synchronization or it may require that the synchronization should be preceeded by a delay measurement. The IED may also define if it accepts the time only with or without date or only as a broadcast message. It is also possible to synchronize the device from an external time source and it need not be done from SYS 600 at all. Steps 4 and 5 require SYS 600 application programming. With protocols implemented to process communication unit PC-NET, a common practice is to define a time channel or a set of time channels which are executed with a defined interval. A command procedure which actually initiates the synchronization is then connected to the time channel. Example for DNP3.0 master protocol:
#LOOP_WITH I=20..25 #IF STAI:SIU==1 AND STAI:SOS==0 #THEN #BLOCK #SET STAI:SSY=(1,0) ; direct, no time delay measurement #PAUSE 10 #BLOCK_END #LOOP_END
If this procedure is attached to a time channel, which is executed with 1 hour interval, the IEDs related to STA20..STA25 are synchronized once every hour. The same station object attribute SY is used for time synchronization in most protocols implemented to PC-NET. For more details, refer to the protocol specific manuals and System Objects manual.
3.7.1.1.
106
1MRS756112
A070709
Fig. 3.7.1.1.-1
3.7.2.
3.7.3.
To display old time tags correctly The site may have been moved from a time zone to another, or daylight saving time may have been applied differently in the past. As the base system stores the time tags in UTC time, the history is needed to correctly convert the tags to the local time of the moment of event.
1MRS756112
The base system transfers the current time zone and daylight saving information from the operating system at each system startup and maintains the history automatically. However, there are a few cases, where you might want to edit the history explicitly:
*
Time zone and/or daylight saving time settings are changed and it is not acceptable to shut down and restart the system for this reason. Prior to SYS 500 revision 8.4.4, the time tags were stored in local time. If a revision 8.4.3 application or older is upgraded and the time zone and/or daylight saving time settings have been changed during the age of the application, the old settings should be copied to the base system to display old time tags correctly. If it is known that time zone and/or daylight saving time settings are to be changed in the future, it is useful to transfer the new settings to the base system in advance. Then, the base system is able to correctly time the once-only time channels scheduled after the coming change of settings. In addition, other local/ UTC time conversions of future time tags are done correctly.
The explicit editing of SYS_TIME.PAR is done with SCIL function TIME_ZONE_RULES, refer to the Programming Language SCIL manual. As there are some complications of local/UTC time handling, it is recommended that engineering of a new application is done in a PC that uses the time zone and daylight saving time settings of the target site.
3.7.4.
TF-attribute With TF-attribute the following conventions are available: yy-mm-dd hh:mm:ss, when TF=0 dd-mm-yy hh:mm:ss, when TF= 1 The default value for time format can be configured in SYS_BASCON.COM, where node for base system is created.
Extract from SYS_BASCON.COM #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 TF = 1,; Time Format
108
1MRS756112
Like Alarm list and Event list, Monitor Pro applications follow time format defined by TF.
Initialization file FRAMEWINDOW.INI FRAMEWINDOW.INI is a user specific file and it is located in directory \sc\apl\' apl name'\PAR\'user name'. The representation order of time and date can be configured in DAYFORMAT section of the above mentioned file. The configuration applies for the Monitor Pro status bar. To learn more about this configuration, see the example given below:
The default represention style in status bar follows the TF-attribute setting. If DAYFORMAT is defined it will be used. A list of all possible options for configuring DAYFORMAT is given below:
*
Month %b, Abbreviated month name %B, Full month name %m, Month as number (01 12)
Week %W, Week of year as decimal number, with Monday as first day of week (00 53) %U, Week of year as decimal number, with Sunday as first day of week (00 53)
Day %d, Day of month as number (01 31) %j, Day of year as number (001 366) %w, Day of week as number (0 6; Sunday is 0) %a, Abbreviated weekday name %A, Full weekday name
Hour %H, Hour in 24-hour format (00 23) %I, Hour in 12-hour format (01 12)
109
1MRS756112
Misc %c, Date and time representation appropriate for locale %x, Date representation for current locale %X, Time representation for current locale %z, %Z, Either the time-zone name or time zone abbreviation, depending on registry settings; no characters if time zone is unknown
3.8.
Configuring networks
Each NET unit, which is connected to a base system via one or more than one units, should be defined to the base system as a node (NODn:B objects): 1. Create a NODn:B base system object corresponding to the indirectly connected communication unit. The NOD object number ('n') should be the same as the node number of the communication unit. The NOD object is given the following attribute values: LI = Link number (= LIN object number). This is the link to the nearest communication unit SA = Station address of the indirectly connected communication units Even if there is no communication between the base system and the indirectly connected NET, the node definition is necessary for the system diagnostics, online configuration and system maintenance. Correspondingly, each base system connected to a NET unit indirectly via other units should be defined to the NET unit as a node. 2. Define an "External node" (NET object) on the line to the nearest communication unit: Device type = NOD Device number = The node number of the indirectly connected base system LI, Line number = The line to the nearest communication unit in the series SA = Station address of the indirectly connected base system 3. Define an application for each application in the indirectly connected base system.
110
1MRS756112
Example: Fig. 3.8.-1 shows an example of a network of two base systems and a Frontend system containing two communication units. Application 1 communicate to process true Front-end system, and APL1 and APL5 (in Base system2) communicate with each other. The example includes only the definitions which are of importance for this particular configuration.
Base system 1 Node number 9 Station address 209 APL 1 Link 1 Frontend system Node number 10 Station address 210 Line 1 Base system 3 Node number 11 Station address 211 APL 5
VS type monitor
Line 12
A070712
Fig. 3.8.-1
Network of two base systems and a Front-end system containing two communication units
111
1MRS756112
3.8.1.
LAN nodes
In the LAN network, each connected base system and workplace has a LAN node name or number. The LAN node names are used in the SYS 600 configuration to achieve communication between base systems, between base systems and LAN connected devices. Use static IP addressing. This indicates that the computer is manually configured to use a specific IP address. Using DHCP for IP assignment is not verified. To get an idea about Base System Configuration, refer to Fig. 3.8.1.-1 :
112
1MRS756112
Fig. 3.8.1.-1
Link to other SYS or LAN frontend (requires TCP/IP) #CREATE LIN:V = LIST(LT = "LAN") ;Link type #CREATE LIN1:B = %LIN #CREATE NOD:V = LIST(;Node for LAN frontend or SYS LI = 1,NN = "TROIJA",SA = 207) #CREATE NOD7:B = %NOD #CREATE NOD:V = LIST(LI = 1,NN = "10.58.125.123",SA = 230) #CREATE NOD30:B = %NOD ;Node for LAN frontend or SYS
3.8.2.
3.8.2.1.
Local applications
Suppose that application 'a' needs to read and write data in application 'b' in the same base system, as shown in Fig 3.8.2.1.-1. Application 'b' should then be "introduced to" application 'a' by means of application mapping (For more information, refer to the System Objects manual):
#SET APLa:BAPi = b
where
113
1MRS756112
'i' The logical application number under which application 'a' recognizes application 'b' To avoid complexity, it is recommended to let the logical number be the same as the object number of the application, that is 'i' = 'b'. For example, setting #SET APL1:BAP2 == 2 means that APL2 is recognized to APL1 by the logical application number 2. In application 1 it is possible to read object data in application 2, for example with the notation: OBJ:2POV1.
A051611
Fig. 3.8.2.1.-1
Illustration of the data communication between applications in the same base system
3.8.2.2.
114
1MRS756112
LI SA
The number of the link to base system 2 (the LINn:B object number, see above) Station address of base system 2
3. Create an external application, an APLn:B object, referring to application 'b' in base system 2. For clarity, use the same object number ('n') as the application object number in base system 2 (although this is not a requirement), that is create APLb:B. Assign the APLb:B object the following attributes:
TT ND TN "EXTERNAL" Node number of base system 2 Application object number in base system 2 ('b')
4. Map the external application in base system 1 to the communicating application, application a, by setting APLa:BAPi = b, where 'i' is the logical application number under which application a recognizes application b. If there are no obstacles, let the logical number be the same as the object number of the application (that is 'i' = 'b').
A051612
Fig. 3.8.2.2.-1
Illustration of the configuration and data communication between two applications situated in separate base systems
115
1MRS756112
3.9. 3.9.1.
3.9.1.1.
* *
Two complete base systems connected to a LAN, each including at least two applications: one main application, which is a part in the hot stand-by relation, and one watchdog application which is dedicated for monitoring the main application and performing a switch over when needed. A local area network (LAN), TCP/IP. A standard watchdog application software package in each base system. The watchdog software package contains command procedures and data objects for monitoring the operation and reconfiguring at switchover.
Options:
* *
The following procedure describes the steps to be taken to configure a hot stand-by base system:
116
1MRS756112
1. Install the MicroSCADA Pro Technology software for both base systems as described in the Installation and Commissioning Manual. 2. Edit SYS_BASCON.HSB template and rename it to SYS_BASCON.COM for both base systems. 3. Start base system that should have the hot application. 4. Install standard watchdog application software. 5. Define external watchdog application and start the main application. 6. Start stand-by base system. 7. Install standard watchdog application software in the stand-by base system. 8. Define external watchdog application software in the stand-by base system. 9. Edit command procedures in the watchdog applications for both base systems.
3.9.1.2.
SYS_BASCON.HSB
The MicroSCADA Pro software delivery includes a version of SYS_BASCON. COM template, SYS_BASCON.HSB, which contains all the necessary configuration definitions for a hot stand-by. The easiest and most reliable method to build the base system configuration for hot stand-by systems is to customize 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 @NO_OF_X = 0 ;# OF VS MONITORS ;# OF X MONITORS
@LINKS = ("*LAN","RAM1","RAM2","INTEGRATED") ;USED LINKS INDICATED WITH PREFIX "*" @BS_NODES = (9,10) @FE_NODES = (1,2) @FE_NODE_LINKS = (1,1) @NO_OF_STAS = 0 @STA_TYP = "RTU" @STA_NOD = %FE_NODES(1) @NO_OF_PRIS = 2 @PRI_TYP = "NORMAL" @PRI_NOD = %FE_NODES(1) ;BASE SYSTEM NODES ;FRONT-END NODES ;LINK NUMBER OF FE NODES ;# OF STATIONS ;DEFAULT STATION TYPE ;DEFAULT NODE FOR STA ;# OF PRINTERS ;DEFAULT PRINTER TYPE ;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")) #CREATE SYS:B = LIST(-
117
1MRS756112
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 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, 2=INFORMATION, - ;3=AUDIT_SUCCESS, 4=AUDIT_FAILURE) Bit_Mask(0,1,2,3,4))) ;Security events (Bit 0=ERROR, 1=WARNING, - ;2=INFORMATION, 3=AUDIT_SUCCESS, 4=AUDIT_FAILURE) ;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 #CREATE STA:V = LIST(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 #CREATE PRI:V #SET PRI:VND=%PRI_NOD #SET PRI:VDT=%PRI_TYP
118
1MRS756112
;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 #CREATE APL:V #SET APL:VNA = #SET APL:VTT = #SET APL:VAS = #SET APL:VPQ = #SET APL:VMO = #SET APL:VPR = *** LOCAL WATCHDOG ***
"WD" ;APPLICATION NAME "LOCAL" ;TRANSLATION TYPE "HOT" ;APPLICATION STATE 2 ;PARALLELL QUEUES %MON_MAP ;MONITOR MAPPING %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(-
119
1MRS756112
;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) ;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 = 1 ;SHADOW MAXIMUM RECEIVE WAIT TIME IN SECONDS #SET APL:VSI = 100 ;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 #LOOP_WITH I = 1 .. LENGTH(%APL_NUMS) @NUM = %APL_NUMS(%I) #SET APL:VAP(%NUM) = %NUM #LOOP_END @APLN = %APL_NUMS(1) #CREATE APL'APLN':B = %APL ;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 @APLN = %APL_NUMS(4) #CREATE APL'APLN':B = %APL ;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 @APLN = %APL_NUMS(3) #CREATE APL'APLN':B = %APL ;ADJ_MAIN_APL_END ; ;Station Types #SET #SET #SET #SET #SET #SET STY3:BCX STY4:BCX STY5:BCX STY6:BCX STY7:BCX STY8:BCX = = = = = = "ANSI X3-28" "SPIDER RTUs" "SINDAC (ADLP80 S)" "P214" "SINDAC (ADLP180)" "PAC-5"
120
1MRS756112
CX CX CX CX CX CX CX
= = = = = = =
To configure the hot stand-by functionality in SYS_BASCON.HSB, follow the steps given below: 1. Edit the variables in Table 3.9.1.2.-1 in the beginning of the file. For more information, refer to the SYS_BASCON.HSB file above.
Table 3.9.1.2.-1
SYSTEMS THIS_IS
APL_NAME
APL_NUMS
2. Define the base system as a SYS:B object with the Shadowing attribute SH = 1. The main application (APLn:B) attributes which are significant in shadowing configuration are described in Table 3.9.1.2.-2:
Table 3.9.1.2.-2
Application State Application Mapping
MO SN
Shadowing Watchdog
SW
1MRS756112
The maximum time interval between shadowing data transmission The time interval between diagnostic commands from the primary system to the hot stand-by Time-out for contact taking with the stand-by application Time-out of the hot stand-by connection Time synchronization interval
SI
SC
SR SY
The standard base system configuration defines that both main applications are COLD when the base systems are started, only the watchdog applications are running. The principles for the initial configuration of a hot stand-by base system in SYS_BASCON.HSB are also shown in Fig. 3.9.1.2.-1.
A051616
Fig. 3.9.1.2.-1
The example in Table 3.9.1.2.-3 illustrates only the attributes and parameters that are significant for hot stand-by:
122
1MRS756112
Table 3.9.1.2.-3
Base system: SH=1
Application 2 (internal, default application): Application 2 (internal, default application): * NA = WD * NA = WD * AS = HOT * AS = HOT Application 3 (external): NA = ADJ_MAIN * TT = EXTERNAL * ND = 10 * TN = 1
*
3.9.1.3.
Watchdog application
The watchdog application software package handles the following procedures for all hot stand-by applications within a base system:
*
When the base system is started, it checks which main application was operating last and sets the application state (AS) to HOT and the shadowing state (SS) to HOT_SEND. During the operation, it monitors the messages sent from the hot application. If no messages are received in a specified time defined by the Shadowing Receive Timeout (SR) attribute a switchover is started and the stand-by application is set to HOT and shadowing is started (SS = HOT_SEND) when the connection is reestablished. If the hot system does not get acknowledgments from the stand-by system, it regards the connection as broken, and the shadowing stops (SS = NONE). The watchdog application then checks the connection by sending commands cyclically (with a few minutes interval) to the stand-by system, and starts shadowing (SS = HOT_SEND) when the connection is re-established.
1MRS756112
Installed Package Version: The name and revision date of a previously installed package. Status: The status of the installed package, running or not running.
Disk Package Version: The hot stand-by software package installed on a disk. Status: The status of the disk package (OK, DISK PACKAGE NOT FOUND or FILE READ ERROR (SHAD_VERS.CIN): error number).
3. Click Install to install the watchdog software package. The installation creates a set of command procedures, data objects and time channels. When the installation is complete, the name and revision date of the package appears in the Installed Package Version field.
SHADUSR
The generation of alarms and events in the situations when: * Hot stand-by transmission starts * File and RAM dump is ready * Connection is lost to the receiver (in the stand-by system) * Takeover starts * Change of state occurs in the partner application. The shifting of classic monitors at takeover, for example, mapping monitors for the main application, or opening application windows using the SCIL function OPS_CALL and the mons.exe command. For more information on how to open application windows, refer to the Installation and Administration manual. When a monitor is mapped to an application, an event channel MON_EVENT is activated. This can also be used in registering the SD attribute of an X terminal, for example, in the Instruction (IN) attribute of a command procedure. At switchover, the SD attribute can be used for opening a window in the same terminal.
SHADMAPMON
124
1MRS756112
SHADMAPNET
Reconfiguration of the communication units at takeover. This is currently not the primary method to use for the reconfiguration. The redundancy configuration of communication units is described in detail in chapters 3.9.2 3.9.7. In case the PC-NET process communication units are distributed as described in Chapter 3.3.3 Distributed process communication units Distributed process communication units, the redefinition of the APL objects of the PCNET units should be done using the SY attribute of the PC-NET node. This can be done by editing the SHADMAPNET procedure or from a separate procedure connected to the APL_INIT_H event channel of the main application. Specifies whether the main application is allowed to be set HOT when a lost connection has been discovered. The command procedure can contain a check of the error, for example, if the communication disturbance is due to a communication fault on the LAN connection to the stand-by system. Then no switchover should be performed. By default, the application is set to HOT. Specifies whether the main application is allowed to remain HOT when also the standby application is HOT. Such situation can occur at a LAN break. By default, the application remains HOT.
SHADGOHOT
SHADREMHOT
3.9.1.4.
Shadowing
To define the external watchdog application and enable hot stand-by, follow the instructions given below: 1. Click Shadowing Applications. A list of HSB applications is shown in the dialog. 2. Click the row of the local main application that you want to modify and click the Edit button. 3. Check the HSB check-box to set the HSB On. 4. Select the external watchdog application in the drop down list and click OK (or Apply and Cancel). 5. Repeat steps 2-4 for each main application. File dumps and shadowing will start after the HSB has been enabled for the main applications in both base systems. A takeover should not be done before the file dump is completed.
125
1MRS756112
The file dump of an application is completed when the shadowing state attribute SP = HOT_SD.
3.9.2.
3.9.2.1.
The application logic for handling External OPC Data Access client stopping and starting has been included into a separate command procedures in the WD application. The reason for stopping the External OPC Data Access client is related to the situation that MicroSCADA Pro SYS 600 may have been stopped abnormally due to some computer failure. In these circumstances the standard routines related to the shutdown of SYS 600 base system's SHUTDOWN.CIN execution nor stopping of application (APL_CLOSE event channel execution) has been handled normally. An example of these command procedures is given below.
;STOP_OPC_DA_CLIENT_INSTANCE:C in HSB systems for WD application ... @opc_status = ops_call("C:\sc\prog\OPC_Client\DA_Client\daopccl.exe -id ""conf"" -stop", 0) ;START_OPC_DA_CLIENT_INSTANCE:C in HSB systems for WD application ... @opc_status = ops_call("C:\sc\prog\OPC_Client\DA_Client\daopccl.exe -id ""conf"" -start ""C:\sc\sys\active\sys_\config.ini"" -trace normal", 0)
For detailed information about the usage of DAOPCCL.EXE and its parameters, refer to the SYS 600 External OPC Data Access Client manual.
126
1MRS756112
3.9.2.2.
The station communication can be activated as described in the following command procedure:
;STAS_IN_USE:C in HSB systems for MAIN application ... #error continue @i_Sta_Numbers = (81,82,83,84,85) #loop_with lc = 1..length(%i_Sta_Numbers) @i_Sta_Number = %i_Sta_Numbers(%lc) #set sta'i_Sta_Number':sIU = 1 ;station in use #set sta'i_Sta_Number':sUP = 1 ;update points #loop_end
3.9.3.
3.9.3.1.
PC-NET configuration
The PC-NET configuration made with the System Configuration Tool should be entered from the watchdog (WD) application. With this approach, the configured PC-NET instances are automatically started when MicroSCADA is started and the PC-NET instances are already configured when the MAIN application goes hot in all situations. When the system configuration is entered from the WD application, the AS and MS attributes of the STA objects created for the PC-NET will also refer to WD application. The AS attribute defines the application that will receive process data messages and the MS defines the application where the system messages from the station object will be sent for. In order to map the incoming process data and the status messages to the main application, the following configuration should be entered to the configuration of the NET node. In this example, the number of the main application is 1 and the number of the WD application is 2.
127
1MRS756112
A071120
Fig. 3.9.3.1.-1
An alternative method is to add the following script to the "User-Defined" program of the NET node.
@MAIN_APL = 1 @WD_APL = 2 #SET NET'i_Net_Number':SSY'WD_APL'= (SYS:BND, %MAIN_APL) #SET NET'i_Net_Number':SSY'MAIN_APL'= (SYS:BND, %WD_APL)
This script should be present in HSB configuration, otherwise the process data will be sent to the WD application. Furthermore, all lines created to PC-NET process communication units should be configured to have IU=0, which means, all lines should be out of use by default.
3.9.3.2.
Activating communication
The communication to the station and to NCCs should be activated when state of the main application turns to HOT. In practise, a command procedure attached to event channels APL_INIT_1 and APL_INIT_H of the main application should loop all lines created to PC-NET nodes and take the line into use. The LON protocol (if created to the system) requires special handling. With LON protocol, it is required that the stations objects should be taken into use after the line has been taken into use. In practise, this means that all the mentioned procedure should contain a block.
#SET #SET #SET . #SET NET3:SIU1 = 1 STA20:SIU = 1 STA21:SIU = 1 STA80:SIU = 1 ;LON line 1 in NET3 ;REX station connected to LON line 1 ;REX station connected to LON line 1 ;LMK station connected to LON line 1
No other station types, except REX and LMK, need to be taken out of use and back to use when the communication activation and deactivation is required to perform.
128
1MRS756112
The event channel APL_INIT_1 in the main application is executed when system is started and the state of the main application is "HOT" immediately after the startup. APL_INIT_1 is not executed in normal take-over. The event channel APL_INIT_H is activated when the take-over occurs and the state of the main application changes from "COLD" to "HOT". For more information about the predefined event channels APL_INIT_1 and APL_INIT_H, refer to the Application Objects manual. With the COM500i application, the communication activation procedure should be executed before the COM_COMINI_H and COM_COMINI procedures in APL_INIT_H and APL_INIT_1.
3.9.3.3.
Deactivating communication
When the main application turns to COLD state, it necessary to deactivate all communication. The deactivation is made from a commands procedure connected to event channel APL_CLOSE of the main application. The behaviour is opposite compared with the activation presented in the previous chapter. Like in the activation, the LON protocol (if created to the system) requires special handling. In this case, it is required that the stations objects should be taken out of use, before the line has been taken into use.
#SET #SET . #SET #SET STA20:SIU = 0 STA21:SIU = 0 STA80:SIU = 0 NET3:SIU1 = 0 ;REX station connected to LON line 1 ;REX station connected to LON line 1 ;LMK station connected to LON line 1 ;LON line 1 in NET3
No other station types, except REX and LMK, are needed to be taken out of use and back to use, when the communication activation and deactivation are required to be performed.
3.9.4.
129
1MRS756112
Like in other process communication units, the activation and the deactivation of the communication should be made from command procedures executed from event channels APL_INIT_1, APL_INIT_H and APL_CLOSE of the main application. The communication activation procedure should be executed before the COM_COMINI_H and COM_COMINI procedures in APL_INIT_H and APL_INIT_1.
3.9.5.
3.9.5.1.
4. Edit the "CONFIG.INI" in each directory and make the corresponding configuration to the base system, as instructed in Modbus Slave Protocol manual of MicroSCADA. The number of the main application should be given to the configuration item "application_number". 5. Create a BAT-file MDS1.BAT with the following contents:
130
1MRS756112
Create a similar BAT-file for each instance to their own subdirectory. 6. Add the following script to a command procedure executed from event channels APL_INIT_1 and APL_INIT_H of the main application.
;MD_SLAVE_START:C @MDS1_STATUS = OPS_CALL("C:\sc\prog\modbus_slave\s1\MDS1.BAT",0) @MDS2_STATUS = OPS_CALL("C:\sc\prog\modbus_slave\s2\MDS2.BAT",0) @MDS3_STATUS = OPS_CALL("C:\sc\prog\modbus_slave\s3\MDS3.BAT",0)
7. Add the following script to a command procedure executed from event channel APL_CLOSE of the main application.
;MD_SLAVE_STOP:C @MDS1_STATUS = OPS_CALL("taskkill /IM mds1.exe /F",0) @MDS2_STATUS = OPS_CALL("taskkill /IM mds2.exe /F",0) @MDS3_STATUS = OPS_CALL("taskkill /IM mds3.exe /F",0)
8. Define the NCC connections to the Signal X-reference tool in the base system. The entered RTU station numbers should be equal to values entered to CONFIG. INI files, item stn_no_1. The com500i initializes the modbus databases in the order NCC1, NCC2. and so on. If some of the modbus slaves requires faster communication start-up after a takeover, it is preferred to configure it to a smaller NCC number compared to others.
3.9.5.2.
Activating communication
The communication to the NCCs will be activated when the state of the main application turns to HOT. In this situation, if the configuration step 5 in Chapter 3.9.5.1. Modbus slave configuration is completed, instances MDS1.EXE, MDS2.EXE and MDS3.EXE should be found from the process list of the computer. The operation of each of these instance can be tested as instructed in Modbus Slave Protocol manual. Furthermore, the starting and the stopping of the modbus instances can be tested by executing the command procedures mentioned in step 5 and 6 (in Chapter 3.9.5.1. Modbus slave configuration ). The event channel APL_INIT_1 is executed when system is started and the state of the main application is HOT immediately after the start-up. APL_INIT_1 is not executed in normal take-over. The event channel APL_INIT_H is activated when the state of the main application changes from COLD to HOT. For more information about the predefined event channels APL_INIT_1 and APL_INIT_H, refer to the Application Objects manual. The communication activation procedure should be executed before the COM_COMINI_H and COM_COMINI procedures in APL_INIT_H and APL_INIT_1.
131
1MRS756112
3.9.5.3.
Deactivating communication
When the main application turns to COLD state, it necessary to deactivate all communication. In this situation, if the configuration step 6 is completed as instructed, instances MDS1.EXE, MDS2.EXE and MDS3.EXE will disappear from the process list of the computer and the communication to the NCCs are at least temporarily stopped. For more information about the predefined event channel APL_CLOSE, refer to the Application Objects manual.
3.9.6.
132
1MRS756112
The rules 2 and 3 need not to be followed if it is known that the remote device is capable to handle concurrent connections.
With the COM500i application, the communication activation procedure should be executed before the COM_COMINI_H and COM_COMINI procedures in APL_INIT_H and APL_INIT_1.
3.9.7.
A070469
Fig. 3.9.7.-1
133
1MRS756112
Limitations
* *
No keep-alive connection from NCCs to stand-by COM 500i Switch is initiated by the hot stand-by application of COM 500i and not by the NCCs Events can be lost or doubled when switch-over occurs in COM 500i
3.9.7.1.
APL_INIT_H
APL_INIT_H is activated when the switch-over occurs and the state of the main application changes from COLD to HOT. COM 500i writes automatically command #DO COM_COMINI_H:C to APL_INIT_H command procedure, when the main application is opened the first time after installation. The COM_COMINI_H command procedure starts initialization of COM 500i after switch-over (as shown in Fig. 3.9.7.1.-1).
134
1MRS756112
A071121
Fig. 3.9.7.1.-1
Communication units
For more information, refer to Communication units configuring in Section 3.9.2. Hot stand-by with OPC client and servers, Section 3.9.3. Hot stand-by with PCNET , Section 3.9.4. Hot stand-by with CDC-II slave, Section 3.9.5. Hot stand-by with Modbus slave and Section 3.9.6. Hot stand-by with CPI applications.
A071122
Fig. 3.9.7.1.-2
135
1MRS756112
3.10.
Configuring mirroring
Process database mirroring is defined on station (STA:B) object level: a station in SYS 600 that is connected to a PC-NET or some other data source, the host station, is connected to one or more image stations located in other applications, usually in other MicroSCADA Pro machines. One host station can have up to 10 image stations. In a hierarchical mirroring system, each image station can in turn act as a host to upper-level image stations. The role of a station object and its mapping to a station located in the external application are defined by a couple of station object attributes. The application containing the host station is called host application (of the station) and the application containing the image station is called the image application (of the station). Note however that an application can have both host and image stations, so it can act in different roles for different stations. The process objects of a host station and an image station are mapped according to their object address (OA and OB) or source name (IN or IN/EH of OPC based objects). If the object address or the source name of a process object is identical in the host and image database, the objects are considered to denote the same signal in the station device. The logical names of the process objects can be different in different databases. All the process objects in an image database that are in use (IU = 1) have the switch state AUTO (SS = 2) and map to an in-use AUTO state process object in a host database, are subject for mirroring. No new process object attributes are used to configure mirroring communication. An image application subscribes to the events of process objects in its process database. The image database can only contain a subset of addresses found in the host database, the uninteresting signals can be dropped from the communication load. The mirroring function contains the following sub-functions: 1. The host application replicates the messages from the station device to each image application that has subscribed to the object address. 2. The process commands (#SET and #GET) executed in an image application are routed to be executed by the host application. The changed OV value is sent to the image applications by the host. 3. Any access of STA:S attributes in an image application is routed to be executed by the host application. 4. The host application replicates the system messages from the NET to each image application that has subscribed to the system messages. The mirroring communication between the host and image application is implemented as APL-APL communication. Consequently, LAN, WAN and serial communication can be used. The APL-APL communication between the host and image applications must be configured to enable mirroring.
136
1MRS756112
The communication between the host and the image is buffered and the communication breaks are handled automatically. The events that have occurred during the break are sent when the connection is re-established. The hot stand-by configurations are supported and the switchovers are handled automatically without losing any events. Mirroring can be disabled or enabled on a host/image application pair basis by means of APL object attributes. When mirroring is disabled, the host buffers events, just as during other types of communication breaks. Significant mirroring events, such as established or lost connections and configuration mismatches, are reported to the application via application events (event channels APL_EVENT and HOST_ADDRESS_MISSING). Diagnostic counters, implemented as APL object attributes, help monitoring the traffic between the host and image application. Because it is possible to create very large image applications by using the mirroring function, the maximum number of STA base system objects (MAX_STATION_NUMBER in SCIL) is 5000.
3.10.1.
Station mapping
There are three station (STA:B) attributes that define the role and addressing of the station in the mirroring network. The MR (Mirroring Role) attribute defines the role of the station:
*
MR = HOST: This is a host station that transmits the process data to one or more image stations defined by the attribute IS MR = IMAGE: This is an image station that receives the process data from the host station defined by the attribute HS MR = BOTH: This is an image station that receives the process data from the host station defined by the attribute HS. Furthermore, it acts as a host station to the image stations defined by the attribute IS MR = NONE: This station does not participate in mirroring (default)
The HS (host station) attribute of an image station object defines where the corresponding host station is to be found. It has a list value with the following attributes:
APL UN The number of the (usually external) host application The unit number of the host station in the host application
The IS (Image Stations) attribute of a host station object defines where the corresponding image stations are found. The attribute is a vector of up to 10 list values with the following attributes:
137
1MRS756112
APL UN
The number of the (usually external) image application The unit number of the image station in the image application
3.10.2.
Process messages
In principle, all the messages from the station device to the host database are replicated by the host database and sent to the image applications that have subscribed to the object address. For the load control, however, some measurement events can have been dropped. For more information, refer to Section 3.10.7. Buffering and communication breaks. In a hierarchical mirroring network, the image application can also act as a host and re-replicate the messages and send them further to their upper-level image applications. The substituted values of the process objects (the ones written by SCIL along with the SU attribute) are handled as real process values, that is, they are subject to the mirroring as well. This feature can be used to send mirroring events by SCIL. Define an AUTO state process object with a pseudo-address (an address having no real counterpart in the process station) and write to it by using the following notation:
#SET ABC:P1 = LIST(OV = 1, SU = 1)
3.10.3.
Process commands
Process commands, that is #GET commands and #SET commands of the OV (BO, DO, AO or BS) attribute of an AUTO state process object, are sent to the host application which executes them on behalf of the image application. In a hierarchical mirroring network, the commands are delivered to the lowest level host. If the command is 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.
3.10.4.
138
1MRS756112
3.10.5.
System messages
System messages from the NET are delivered to image applications in a similar way as process messages. The difference in configuration is that in the host application the system messages are always sent to virtual unit number 0. In the image application, a non-zero unit number must be reserved for each host whose system messages are received. This unit then represents the virtual unit 0 of the host. As in process messages, the process objects within this unit and the host unit 0 are mapped by their object addresses. In the STA object of the image database, the unit is mapped to unit 0 of the host application by setting HS = LIST (APL = host_application, UN = 0). When the image application starts up, it subscribes to the system messages (object addresses) of the unit in the same way as it subscribes to the process messages. In the host application, no STA objects related to system message mirroring are needed because system messages are always received to unit 0. Instead, the image stations which receive system messages are listed in a new application attribute IS (Image Stations for System Messages). The IS attribute of the host application is similar to the IS attribute of a host station. It is a vector of up to 10 list values, which define the image stations mapped to the system messages of this host application.
3.10.6.
Subscriptions
The communication between the host and image is subscription-based. When the image application successfully connects to the host, it scans through its process database and sends a list of object addresses that it is interested in, that is the addresses that:
* * *
Are in use Are in AUTO switch state Belong to a unit (station) that is connected to the host.
When the host receives a subscription, it immediately sends back the current value of the object (with CT, cause of transmission, set to INTERROGATED). If the requested object address is not found in the host database, an ADDRESS_MISSING event is sent back. An address is unsubscribed when a mirrored process object in the image database is:
* * *
On the other hand, when an in-use AUTO object is created, the image application automatically subscribes to its events.
139
1MRS756112
When an object with subscriptions to it is deleted or its state switched from in-use AUTO state in the host database, an ADDRESS_MISSING event is sent to all the subscribers. When a new process object is created (or switched to in-use AUTO state), a NEW_ADDRESS event is sent to the image applications. They can then decide to subscribe to its events. The database of the image application can only be a subset of the host database, thereby reducing the required communication rate. Each image application does its own subscription. The subscriptions can be different.
3.10.7.
* *
The EM attribute (Event Queue Length Maximum) of the application defines the maximum length of the queue. The EU attribute (Event Queue Used) shows the current length of the queue. The EP attribute of the APL object (Event Queue Overflow Policy) specifies the policy to be followed when the maximum length is reached.
EP = DISCARD: The queue is destroyed, an overflow message is sent to the image and the communication is stalled. In this case, the image application does a general interrogation to the host database, but some events can be lost. EP = KEEP: The events are not allowed to be lost. In this case, the process communication between the host application and PC-NET is slowed down just as if the EU attribute of the host application would have reached EM.
The KEEP policy is considered only during the established communication between the host and image. If the limit is reached during a communication break, the DISCARD policy is used. When the connection to the image application is lost, the host only buffers events without trying to send them. When the image application (or its HSB partner, if there has been a take-over at image site) succeeds in re-establishing the connection, it sends the sequence number of the last received message to the host and requests retransmitting of newer events. If the host still has the requested events in its buffer, it sends them and no events are lost. If the requested events are no longer available because queue length reached its maximum during the break or because the host has been down, the image application does a new subscription and events can be lost. During a communication break, the process objects in the image database are marked as old by setting the object status value to 2.
140
1MRS756112
The load control in the communication is done by reducing the rate of measurement events. Measurement event means a process message to an analog input process object when all the following conditions are met:
*
The object has a real value representation. Integer valued AI objects, that is the ones with IR = 1, are not considered as measurements. The event is a measurement event according to the load control policy of the station. The object address is not included in the list of analog event addresses (attribute AE) of the station.
The LP (Load Control Policy) attribute of the station (STA:B) object defines which analog events can be considered as measurement events according to the description above. The attribute can take one of the following four values:
"KEEP_ALL_ANALOGS" No analog messages are taken as measurements. The messages that are not timestamped by the station are taken as measurements. The analog messages are taken as measurements whether they are timestamped or not. The LP attribute of the corresponding STY object is applied.
"KEEP_TIME_STAMPED_ANALOGS"
"KEEP_NO_ANALOGS"
"DEFAULT"
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, refer to the System Objects manual. The AE (Analog Events) attribute of the station (STA:B) object is defined in the host system. Its value is an integer or text vector of any length and it contains a list of the analog input object addresses (OA) or OPC item names (IN) within the station that are not to be taken as measurements in the sense described above.
3.10.8.
Hot stand-by
HSB switchovers are automatically taken care of and no SCIL command procedures are involved. To be able to do this, the base system should know which external applications make up an HSB pair. Therefore, the SN (Shadowing Number) attribute of the external applications that participate in mirroring should be set. Either of the two applications numbers can be defined as the APL attribute of the HS or IS attribute of the stations participating in the mirroring.
141
1MRS756112
For example, if in an image system the external host applications 7 and 8 make up an HSB pair, the SN attribute of APL7 should be set to 8 and the SN attribute of APL8 should be set to 7. Either 7 or 8 can be defined as the APL attribute of the HS attribute of the stations located in the host. No events are lost due to HSB switch-overs because the mirroring event queues are shadowed by the host application and the events are sequence-numbered. After an HSB switchover of the host or the image application, the image application asks the host to retransmit all the events that are newer than the last received event.
3.10.9.
Disabling mirroring
In an image system, the mirroring communication with a particular host application can be temporarily disabled by setting the HE (Host Enabled) attribute of the host's APL object to 0. Mirroring is re-enabled by setting the attribute back to 1. In a host system, the mirroring communication with a particular image application can be temporarily disabled by setting the IE (Image Enabled) attribute of the image's APL object to 0. Mirroring is re-enabled by setting the attribute back to 1. 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.
3.10.10.
Application events
Various significant mirroring events are reported to the application via application event channels APL_EVENT and HOST_ADDRESS_MISSING. For full description of these event channels, refer to the Application Objects manual. HOST_ADDRESS_MISSING is used in an image application to log the object addresses that according to the image database should be mirrored but are not found in the host database. APL_EVENT is used both in the host and in the image application. The events reported by the event channel in the image application are the following:
Source UN Event MISSING Description The connection to the host station cannot be established because of a mismatch in STA object configuration between the image and the host. The connection to the host station is lost because the mirroring configuration (either MR or IS) in the host has been changed. The connection to the host station is established because the mirroring configuration in the host has been changed.
LOST
FOUND
142
1MRS756112
Table 3.9.7.1.-2 Start-up configurations for two redundant base systems (Continued)
Source Event "HOST_LOST" Description 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, but the configuration mismatch is detected on a lower level. The configuration problem lower in the mirroring hierarchy has been fixed. The connection to the host is established. The connection to the host is lost. The connection to the host has been lost because there are no stations connected to the host anymore. The connection to the host is re-established without losing any events. The event buffer of the host has overflown. Events have been lost. The connection to the host has been disconnected by the host, because the host application is shutting down. The communication with the host has been disabled by setting APL:BHE to 0. The communication with the host has been enabled by setting APL:BHE to 1. The communication with the host has been disabled by the host (by setting APL:BIE to 0). The communication with the host has been enabled by the host (by setting APL:BIE to 1).
The events reported by the event channel in the host application are the following:
Source IMAGE Event CONNECTED LOST DISCONNECTED RECONNECTED OVERFLOW BLOCKING Description The connection to the image is established. The connection to the image is lost. The image application has disconnected the mirroring session. The connection to the image is re-established without losing any events. The event buffer for the image has overflown. Events have been lost. The event buffer for the image is full, but because of the defined event queue overflow policy "KEEP", the buffer is not discarded. The connection is now blocking (or slowing down) the communication between the SYS and the NET in order not to lose any events in the image application.
143
1MRS756112
Table 3.9.7.1.-2 Start-up configurations for two redundant base systems (Continued)
Source Event NON_BLOCKING Description The event buffer for the image is not full anymore. The connection does not slow down the communication between the SYS and the NET anymore. This event is generated when the length of the event queue (EU) has dropped below 90 % of its maximum (EM). The communication with the image has been disabled by setting APL:BIE to 0. The communication with the image has been enabled by setting APL:BIE to 1. The communication with the image has been disabled by the image (by setting APL:BHE to 0). The communication with the image has been enabled by the image (by setting APL:BHE to 1).
IMAGE_ENABLED
3.10.11.
Configuration examples
The main steps of the mirroring configuration procedure are the following: 1. Create a node for each base system in the mirroring system (and a LAN link). 2. Create an external application for each image in the host system and an external application for each host in the image system. 3. Define the mirroring attributes for each station; the mirroring role (MR) of a station, the image stations (IS) which are to receive events from the host for the host stations and the host station (HS) for image stations. 4. Raise the amount of APL-APL servers (APL:BAA) of each mirroring application to 10. In most real applications, a lower value would do as well, but the cost of 10 servers is low compared to finding out the smallest usable value. If, however, a lower value is preferred, the following rule can be used. In a host application set the APL:BAA attribute to 10 or two times the number of connected image applications, whichever is lower. In an image application, set the AA attribute to 10 or two times the number of connected host applications, whichever is lower. 5. Copy/create the process objects of the image application. The process database of the image system can be a subset of the host process database. All process objects, which are of interest, can be copied from the host to the image. 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.
144
1MRS756112
3.10.11.1.
A051613
Fig. 3.10.11.1.-1
This is a basic configuration. Process database events of a host base system are mirrored to an image base system. Configuring the host base system The configuration of the host base system is described first. Mirroring requires base system node and external application additions in SYS_BASCON.COM. A LAN link, link number 1, is assumed to exist already. In this example, the node number of the host base system is 232 and the node name is SYS_H. The node number of the image base system is 228 and the node name is SYS_I. A base system node for the image:
#CREATE NOD228:B = LIST(- ;Node for SYS_I LI = 1,NN = SYS_I,SA = 228)
Mirroring attributes of the host stations can be defined in the user-defined programs of the System Configuration Tool. The definition can be written in the user-defined program of each station, or definitions can be grouped in the user-defined program of the net node. If the System Configuration Tool is not used, the mirroring attributes can be defined in SYS_BASCON.COM. The definition should be written for each mirroring station; the definitions for unit 51 serve as an example in the following:
#SET STA51:BMR = HOST #SET STA51:BIS = VECTOR(LIST(APL=2, UN=51))
The host application is connected to one image application, so there should be at least two APL-APL servers.
#SET APL1:BAA = 2
145
1MRS756112
Now the host part of the mirroring configuration is ready. Configuring the image base system A base system node for the host:
#CREATE NOD232:B = LIST(- ;Node for SYS_H LI = 1,NN = SYS_H,SA = 232)
The mirroring configuration additions of the stations in the image base system can be written in SYS_BASCON.COM. Mirroring attributes for stations (station 51 as an example):
#SET STA51:BMR = IMAGE #SET STA51:BHS = LIST(APL=2, UN=51)
The image application receives messages from one host, which defines that the number of APL-APL servers should be at least 2.
#SET APL1:BAA = 2
Now the configuration of the image system is ready. Both base systems can now be started and the process objects which are of interest are copied from the host to the image. System messages Some additional configuration is required to get the system messages from the NET to the image. In the host application, the attribute IS should be defined to introduce the image station which is to receive system messages.
#SET APL1:BIS = vector(list(APL=2, UN=91))
In the image system the respective station, here unit number 91, should be created to receive system messages from the host.
#CREATE STA91:B = LIST(TT = EXTERNAL,ST = RTU,MR = IMAGE,HS = LIST(APL=2, UN=0) TN = 91)
This unit 91 in the image base system now represents the virtual unit 0 of the host, and system messages from the NET are delivered to the image application.
146
1MRS756112
3.10.11.2.
A051614
Fig. 3.10.11.2.-1
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. Configuring the host base system The base system nodes for the image base systems are required and should be created in SYS_BASCON.COM of each host base system.
#CREATE NOD228:B = LIST(- ;Node for SYS_I1 LI = 1,NN = SYS_I1,SA = 228) #CREATE NOD229:B = LIST(- ;Node for SYS_I2 LI = 1,NN = SYS_I2,SA = 229)
147
1MRS756112
An external application should be created for each image. The following code is added in SYS_BASCON.COM of each host base system. Note the attribute SN which defines the application number of the shadowing partner. Here the external applications 2 and 3 make up a HSB pair.
#CREATE APL2:B = LIST(TT = EXTERNAL,NA = IMAGE1,ND = 228,SN = 3,- ;Shadowing partner TN = 1) #CREATE APL3:B = LIST(TT = EXTERNAL,NA = IMAGE2,ND = 229,SN = 2,- ;Shadowing partner TN = 1)
Mirroring attributes of the host stations can be defined in the user-defined programs of the System Configuration Tool. The definition can be written in the user-defined program of each station, or definitions can be grouped in the user-defined program of the net node. If the System Configuration Tool is not used, the mirroring attributes can be defined in SYS_BASCON.COM. The definition should be written for each mirroring station; an example of the definitions for unit 51 is given below:
#SET STA51:BMR = HOST #SET STA51:BIS = VECTOR(LIST(APL=2, UN=51))
The host application serves one image application, so there should be at least two APL-APL servers.
#SET APL1:BAA = 2
Now the mirroring configuration of the hosts is completed. Configuring the redundant image base system Make the modifications in one configuration file and then copy the results to the configuration file of the redundant base system. A node should be created for each host base system.
#CREATE NOD232:B = LIST(- ;Node for host 1 (SYS_H1) LI = 1,NN = SYS_H1,SA = 232) #CREATE NOD233:B = LIST(- ;Node for host 2 (SYS_H2) LI = 1,NN = SYS_H2,SA = 233) An external application should be created for each host base system. #CREATE APL5:B = LIST(TT = EXTERNAL,NA = HOST1,ND = 232,TN = 1) #CREATE APL6:B = LIST(TT = EXTERNAL,NA = HOST2,ND = 233TN = 1)
The mirroring configuration additions of the stations for the image base systems can be written in SYS_BASCON.COM.
148
1MRS756112
Mirroring attributes for the stations, here the configuration for stations 51 and 53, is presented as an example. Station 51 receives messages from host 1 and station 53 from host 2.
#SET STA51:BMR = IMAGE #SET STA51:BHS = LIST(APL=5, UN=51) #SET STA53:BMR = IMAGE #SET STA53:BHS = LIST(APL=6, UN=53)
The image application receives messages from two hosts, so there should be at least four APL-APL servers.
#SET APL1:BAA = 4
The mirroring configuration of the image base systems is now ready. All base systems can now be started and process objects can be copied from the hosts to the hot image. Overlapping unit numbers In a mirroring system where process events are gathered from several existing hosts it is possible that the same unit number exists in several hosts. Therefore, after the process objects have been copied, the overlapping unit numbers should be changed in the image application. When defining mirroring attributes for the station, this should be noticed in the host base system . For example if unit 2 exists both in host 1 and host 2, the unit number of the process objects from host 2 should be changed to any valid value which is not in use. Here the new unit number in the image application can be 3. The mirroring definitions for station 2 are:
#SET STA2:BMR = HOST #SET STA2:BIS = VECTOR(LIST(APL=2, UN=2))
in host 1 and
#SET STA2:BMR = "HOST" #SET STA2:BIS = VECTOR(LIST(APL=2, UN=3))
in host 2. In the image base system a new STA object, station 3, should be created with the appropriate mirroring attribute values:
#CREATE STA3:B = LIST(TT = EXTERNAL,ST = RTU,MR = IMAGE,HS = LIST(APL=6, UN=2) TN = 3)
3.10.11.3.
149
1MRS756112
A071292
Fig. 3.10.11.3.-1
Configuring the host base system Mirroring-related configurations for host 1 (SCS_1).
#CREATE LIN:V = LIST(;Link to other SYS or LAN frontend LT = "LAN") ;Link type #CREATE LIN2:B = %LIN #CREATE NOD228:B = LIST(- ;Node for NCC LI = 2,NN = "192.168.10.228",- ;if name used, remember define \etc\HOSTS -table SA = 228) #CREATE APL2:B = LIST(TT = "EXTERNAL",NA = "IMAGE1",ND = 228,TN = 1) ;Mirroring image appl.
150
1MRS756112
Configuring the image base system Mirroring-related configurations for the image.
#CREATE LIN:V = LIST(;Link to other SYS or LAN frontend LT = "LAN") ;Link type #CREATE LIN2:B = %LIN #CREATE NOD231:B = LIST(LI = 2,NN = "192.168.10.231",SA = 231) ;Node for SCS_1 ;if name used, remember define \etc\HOSTS -table
.... #CREATE NOD237:B = LIST(- ;Node for SCS_n LI = 2,NN = "192.168.10.237",;if name used, remember define \etc\HOSTS -table SA = 237) ;SA=230+n #CREATE APL3:B = LIST(- ;Mirroring host appl. TT = "EXTERNAL",NA = "SCS_1",ND = 231,TN = 1) ;Appl. number .... #CREATE APL7:B = LIST(- ;Mirroring host appl. TT = "EXTERNAL",NA = "SCS_7",;n=7 ND = 237,;230+n TN = 1) ;Appl. number
Station STA109 receives messages from unit 9 of host 1 (SCS_1) and STA209 from unit 9 of host 2 (SCS_2).
#SET STA109:BMR = "IMAGE" #SET STA109:BHS = LIST(APL=3, UN=9) #SET STA209:BMR = "IMAGE" #SET STA209:BHS = LIST(APL=4, UN=9) #SET #SET .... #SET #SET STA309:BMR = "IMAGE" STA309:BHS = LIST(APL=5, UN=9) STA709:BMR = "IMAGE" STA709:BHS = LIST(APL=7, UN=9)
Because it is possible to create very large image applications by using the mirroring function, the maximum number of STA base system objects (MAX_STATION_NUMBER in SCIL) is 5000.
3.10.11.4.
1MRS756112
Mirroring configuration of the host Mirroring attributes of the host stations can be defined in the user-defined programs of the System Configuration Tool. The definition can be written in the user-defined program of each station, or definitions can be grouped in the user-defined program of the net node. The definition must be done for each mirroring station. An example of the definitions for unit 51 is given below:
#SET STA51:BMR = HOST #SET STA51:BIS = VECTOR(LIST(APL=2, UN=1051))
Mirroring configuration of the image Mirroring attributes of the image stations can be defined in the configuration file SYS_BASCON.COM. The station 1051 receives messages from the host station 51 in application 1. Therefore, the mirroring attributes for station 1051 are the following:
#SET STA1051:BMR = IMAGE #SET STA1051:BHS = LIST(APL=1,UN=51)
3.10.11.5.
152
1MRS756112
Now the mirroring configuration of the substation is ready. Mirroring definitions of the regional control center The units in the regional control center can both receive messages from the substation (the host) and transmit messages to the main control center (image). The mirroring role MR of such stations must be "BOTH". Mirroring attributes for station 51:
#SET STA51:BMR = BOTH #SET STA51:BHS = LIST(APL=2, UN=51) #SET STA51:BIS = VECTOR(LIST(APL=3, UN=51))
Create two external applications, one for the image and another for the host.
#CREATE APL2:B = LIST(TT = EXTERNAL,NA = SUBS,ND = 232,TN = 1) #CREATE APL3:B = LIST(TT = EXTERNAL,NA = MAIN,ND = 228,TN = 1)
Create nodes.
#CREATE NOD228:B = LIST(- ;Node for the Main Control Center LI = 1,DI = 10,DT = 5,DF = 1,NN = MAINCC,SA = 228) #CREATE NOD232:B = LIST(- ;Node for the Substation LI = 1,DI = 10,DT = 5,DF = 1,NN = SUBS,SA = 232)
Now the mirroring configuration of the regional control center is ready. Mirroring definitions of the main control center Image configuration additions can be written in SYS_BASCON.COM of the main control center base system. The node number of the base system is 228, and the node name is MAINCC. Mirroring attributes for station 51
#SET STA51:BMR = IMAGE #SET STA51:BHS = LIST(APL=2, UN=51
153
1MRS756112
3.11.
A071132
Fig. 3.11.-1
OPC Summary
3.11.1.
DCOM settings
During the SYS 600 installation, the DCOM settings for the usage of OPC communication has been configured automatically into the target computer. The role of DCOM settings is to make distributed applications secure by using the extensible security framework provided by Windows operating systems. This is possible via storing the access control lists for detailed components into registry of target computer. It is possible to see the DCOM settings by using the DCOM configuration tool (Start > Run > DCOMCNFG). The following chapters describe the detailed steps required for the DCOM settings.
154
1MRS756112
3.11.1.1.
the user logged in to the OPC client computer is logged in as a domain user and not a local user. the OPC server computer actually belongs to the domain. If it's a standalone computer, it cannot authenticate the users unless you have a matching user name/ password on both the OPC client and OPC server computer.
3.11.1.2.
3.11.1.3.
155
1MRS756112
3. Click Launch and Activation Permissions > Edit Default. 4. Allow both local and remote access permissions to Anonymous Logon, Everyone, Interactive, Network and System groups. Click OK.
3.11.1.4.
3.11.1.5.
2. Select the General tab, set the Authentication Level to Connect. 3. Select the Security tab > set Customize option > Launch and Activation Permissions > Edit. 4. Allow both local and remote launch and activation permissions to Everyone, Interactive, Network and System groups > OK. 5. Set Customize option > click Access Permissions > Edit.
156
1MRS756112
6. Allow both local and remote launch and activation permissions to Everyone, Interactive, Network and System groups > OK. 7. Select Identity tab, verify that OpcEnum is either run by the launching user or the system account > OK. The DCOM settings on the target machine are now correct.
3.11.2.
157
158
1MRS756112
4.
Configuration tools
4.1. 4.1.1.
A051809
Fig. 4.1.1.-1
The System Configuration Tool dialog includes a menubar and a toolbar. To make the toolbar visible, select Settings > Toolbar Visible. Below the toolbar, there is an object tree on the left side, an attribute tree in the middle and an attribute editing area on the right side. In addition to these, there is an information text bar and a status bar at the bottom of the page, as shown in Fig. 4.1.1.-2.
A051810
Fig. 4.1.1.-2
159
1MRS756112
4.1.2.
A051808
Fig. 4.1.2.-1
4.1.2.1.
160
1MRS756112
A051811
Fig. 4.1.2.1.-1
The attributes are given default values by the tool. Most of the values can be changed. If the value in the editing area is dimmed, editing action will not be allowed.
The working order is from left to right. Changing of value in the attribute tree requires the following steps: 1. 2. 3. 4. 5. Select an object in the Object Tree. Click the + button under the attribute tree to expand all the attribute groups. Select the attribute that you want to configure. Change the value in the editing area. Press Enter.
In the attribute editing area, the on/off values have a check box. A clear check box indicates Off (0) and a selected check box indicates On (1). For integer values, there is a numeric spin box in the editing area, as shown in Fig. 4.1.2.1.-2. The attribute tree is updated, when changes are made in the editing area.
161
1MRS756112
A051812
Fig. 4.1.2.1.-2
4.1.2.2.
4.1.3.
Saving configurations
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. The configuration is saved in the following default files: SYSCONF.INI and SIGNALS.INI. The configuration is available when MicroSCADA 8.4.2 or subsequent SYS_BASCON.COM (sys_bascon$com) template is in use.
4.1.4.
A070486
Fig. 4.1.4.-1
New configuration
If a configuration is already open in the tool, the entire configuration data is cleared from the tool and the contents of the Object tree is replaced with the default configuration. To save the open configuration, copy or rename the SYSCONF.INI and SIGNALS.INI files in the sys/active/sys_ folder.
162
1MRS756112
4.1.4.1.
A051813
Fig. 4.1.4.1.-1
2. After selecting a parent object, there are three ways of adding objects to the configuration. Use one of the following methods:
* *
Keyboard command Ctrl+N Menu bar command Object > New, as shown in Fig. 4.1.4.1.-2
A051814
Fig. 4.1.4.1.-2
*
Fig. 4.1.4.1.-3
163
1MRS756112
A051816
Fig. 4.1.4.1.-4
4. Enter the object number in the text box and click OK, as shown in Fig. 4.1.4.1.5.
A051817
Fig. 4.1.4.1.-5
Fig. 4.1.4.1.-6
4.1.4.2.
Deleting objects
Objects can be deleted by following the steps given below: 1. Select the object from the Object tree. 2. Click the Object menu from the menu bar. 3. Select the object and click Delete. If the object includes user-defined SCIL programs or signals, they are deleted as well.
164
1MRS756112
A051819
Fig. 4.1.4.2.-1
Station 2 is deleted
4.1.4.3.
A051820
Fig. 4.1.4.3.-1
3. Enter the line number of the redundant line in the field, as shown in Fig. 4.1.4.3.2.
A051821
Fig. 4.1.4.3.-2
The redundant line is added to the object tree, as shown in Fig. 4.1.4.3.-3.
165
1MRS756112
A051822
Fig. 4.1.4.3.-3
4.1.4.4.
A051823
Fig. 4.1.4.4.-1
4.1.5.
Configuring dial-up
Some communication lines, for example ANSI X3.28, can be configured to use a dial-up communication. Dial-up protocols are identified in the New Object list when communication line is added to the configuration. In the object tree, an icon is used for dial-up representation and a set of autodialling attributes can be seen in the attribute tree for the selected dial-up communication line, as shown in Fig. 4.1.5.-1.
166
1MRS756112
A060290
Fig. 4.1.5.-1
Dial-up configuration
In online mode, the auto-caller state information is displayed on the Diagnostics page. It can be used for the dial-up communication line. If the specified communication port does not contain a modem or the modem is switched off, the communication line cannot be successfully configured into the communication system (PC-NET). When this occurs, the status codes 10003 NETP_TIMEOUT_WHILE_WAITING_ACKNOWLEDGE or 152 SCIL_NET_COMMUNICATION_TIMEOUT are displayed in the SYS 600 Notification dialog during the configuration.
4.1.6.
167
1MRS756112
The configuration can be saved at any time and this action can be done in both online and off-line mode. In online mode, only the objects that are In Use, are saved with Configuration > Save Active command.
4.1.7.
Online configuration
The online configuration is the current running configuration in the SYS 600 system.
4.1.7.1.
Fig. 4.1.7.1.-1
Loading the online configuration all at once can be a lengthy operation under the following circumstances:
* *
When the configuration consists a great amount of devices When number of devices are located behind slow communication lines or do not respond at all
Thus, it is recommended to open the current online configuration stepwise, for example, the actual loading is not done until the node is expanded. To load the current configuration step by step, select Configuration > Open Online > Stepwise, as shown in Fig. 4.1.7.1.-2.
168
1MRS756112
Fig. 4.1.7.1.-2
After either of the above action, the System Configuration Tool is changed to the online mode. The background color of the object and attribute trees are set to "Lavender" and the text in the lower-right corner is changed to Online when the online mode is selected. Under MicroSCADA Configuration node there is a node called Station Type Definitions, as shown in Fig. 4.1.7.1.-3. This object includes all the different station types, which are displayed when the Station Type Definitions node is expanded. It is not possible to delete this object.
Fig. 4.1.7.1.-3
169
1MRS756112
4.1.7.2.
Fig. 4.1.7.2.-1
*
Dialog informing the user that saving online configuration overrides current configuration files
Click Yes to override the current active configuration in the System Configuration Tool and save the online configuration as the default configuration. Click No to cancel the saving operation. If the menu bar command Configuration > Save Active is selected, the configuration should include a Link object and a NET Node object related to the Link. If the Link object and/or the NET Node object are not present, the PCNET does not start up successfully. Therefore, the configuration becomes invalid and cannot save with the Save > Active command.
4.1.8.
A051825
Fig. 4.1.8.-1
170
1MRS756112
3. Double-click the text Basic Line Attributes or click the + sign in the Attribute tree. This expands the Basic Line Attributes group and shows all the attributes in it.
A051826
Fig. 4.1.8.-2
4. If the IU (In Use) attribute value is 0 (Not In Use), change it to 1 (In Use) in the following way: * In the Attribute tree, click the IU attribute line. * In the attribute editing area, select the IU check box (In Use state).
A051827
Fig. 4.1.8.-3
5. Select Configuration > Save Active from the menu bar. After you have taken the line in use, you can take the stations in that line in use as well.
4.1.9.
Reallocating stations
It is possible to cut, copy and paste the already defined objects in the configuration tree. When you cut an object, it is also deleted from the configuration tree. During the cutting/copying and pasting action, all the related information is copied and reallocated. This includes attribute values, possible user-defined SCIL programs (stations, NET Lines and NET Nodes) and signals (REx, LMK and SPA points).
4.1.9.1.
171
1MRS756112
During cutting/copying 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 an object is not possible if the selected object includes child objects.
4.1.9.2.
Pasting stations
1. In the configuration tree, select the parent object for the object on the clipboard. 2. Select Edit > Paste from the menu bar. The pasted object is a child object for the selected parent object. During the Edit > Paste sequence, the possible signal data is taken into use from the clipboard. This concerns REx, LMK, SPA 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. The configuration object, that is copied into the clipboard, can be pasted several times. The pasted object number collection is based either on the definition of the minimum and maximum object numbers (for example from 1 to 10) or on the definition of individual object numbers (for example 4, 5, 8, 10). The Paste As Range function can be found in the Edit menu.
A051851
Fig. 4.1.9.2.-1
If the copied object includes a set of child objects (for example, copied LMK station includes several SPA stations), the pasting of the object (LMK station) does not include pasting of the child objects (SPA stations). The child objects are required to be copied separately. System Configuration Tool includes error handling during the pasting of objects.
172
1MRS756112
4.1.10.
Previewing
The contents of a currently open configuration file can be displayed in the tool using the Preview function. In this function, the data is shown in SCIL clauses. To show the configuration data, select Configuration > Preview, as shown in Fig. 4.1.10.-1. The SCIL clauses are displayed in the SCIL Editor.
A051625
Fig. 4.1.10.-1
Preview options
4.1.11.
User-defined programs
It is possible to make user-defined SCIL programs for the NET Node, NET Line and Stations. With these programs, you can modify lines and process units with features, which are not yet supported by the configuration tool. For the NET, you can create protocols and devices, which are not yet supported for the lines in the System Configuration Tool.
A051626
Fig. 4.1.11.-1
In the status bar of the System Configuration Tool, there is information for userdefined 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.
173
1MRS756112
1. Select the object to be modified. If the symbol exists in the status bar, you can modify the SCIL program or create a new one. 2. Select Program > User-Defined, as shown in Fig. 4.1.11.-2.
A051627
Fig. 4.1.11.-2
3. Edit your program using the variables listed in the comments of the program.
A051628
Fig. 4.1.11.-3
4.1.12.
174
1MRS756112
A051629
Fig. 4.1.12.-1
3. Type the appropriate values. 4. Click Send to send command to the selected REX station. The Close button closes the dialog without sending any command. Example:
A051630
Fig. 4.1.12.-2
If you enter the same value definitions that you can see in the dialog above, in Fig. 4.1.12.-2, and click Send or press Enter on the keyboard, the following SCIL command is sent to the REX station number one:
#SET STA1:SGO = (1, 1342, 3, 4, 2, 0, 1)
4.1.13.
175
1MRS756112
A051828
Fig. 4.1.13.-1
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.
4.1.14.
System monitoring
System Self Supervision is always dedicated into certain SYS 600 application, which includes sets of command procedures, event channels, time channels, process objects, data objects and parameter files. System Self Supervision functionality can be enabled in the SYS 600 application by using either of the following ways:
*
By installing the first picture function from the LIB 500 System Self Supervision package By selecting the enabled state from the System Self Supervision dialog in the System Configuration Tool
To open the System Self Supervision dialog, select Settings > System Self Supervision in the System Configuration Tool, as shown in Fig 4.1.14.-1.
176
1MRS756112
A051829
Fig. 4.1.14.-1
When the System Self Supervision functionality is enabled in SYS 600 application, the System Configuration Tool does not create supervision routing objects for all the included configuration objects by default. Hence, the user needs to select the appropriate option from the dialog. To remove the supervision routing objects from the previously included configuration objects, it is also required to set that option in the System Self Supervision dialog. If no picture function is installed from the LIB 500 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, removing supervision routing from all the previously included configuration objects requires to set that option in the System Self Supervision dialog. If the System Self Supervision dialog is accessed when previous SYS_BASCON. COM template is being used, an information dialog is displayed. To enable the system self-supervision routing, it is required to include a new attribute, B_SSS_MECH_IN_USE in the base system object definition (SYS:B). An example of this attribute can be found from the new template in the file SYS_BASCON $COM.
A051830
Fig. 4.1.14.-2
Dialog asking to replace the current SYS_BASCON.COM template to enable the System Self Supervision
When the old SYS_BASCON.COM is used during the start-up of SYS 600, the editing of the System Self Supervision dialog is disabled.
177
1MRS756112
If you are using a new SYS_BASCON.COM template during the start-up of SYS 600, you can stop and start the run-time supervision routing in the application. To stop and start the run-time supervision routing, use Run-time supervision routing enabled check box in the bottom of System Self Supervision dialog. An information dialog displays the message whether the action was successful or not.
4.1.14.1.
Supervision log
The System Configuration Tool includes access to Supervision Log. To enter the Supervision Log dialog, select Tools > Supervision Log from the menu bar. The Supervision Log displays all the different events in SYS 600 and the Windows system. Different log types are:
* * * * *
Common system messages Unknown process objects System events from operating system Security events from operating system Application events from operating system
To select the log type, click Log from the menu bar and select the appropriate log type from the menu items. For the events shown in the view, there is a possibility to set a different filter condition, for example, events from a certain station number.
A051831
Fig. 4.1.14.1.-1
4.1.14.2.
178
1MRS756112
Table 4.1.14.2.-1
Attribute TT DT LA
When monitor mapping of application (APLn:BMONnn) is used as a source for monitor supervision, the following semantics in Table 4.1.14.2.-2 is found from the attribute value:
Table 4.1.14.2.-2
Value -1 > 0 and <151
Example:
A051832
Fig. 4.1.14.2.-1
4.1.15.
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. To start the subtools, select Tools > Signal Engineering from the menu bar. The configuration dialog opens. It includes all the signal information for the selected station. To transfer the signal information from the subtool, select Configuration/File > Update from the subtools menu bar. Information is also transferred to the System Configuration Tool, when Configuration/File > Exit is selected. In each of the subtools, there are options to cut, copy and paste signal information.
4.1.15.1.
If there is an enabled symbol, the selected object includes signal information. If there is a disabled symbol, it is possible to include signal information for the selected object, but no signals are created yet. If there is no symbol, it is not possible to include signal information for the selected object.
179
1MRS756112
A051833
Fig. 4.1.15.1.-1
When you select a station in the configuration tree, the attribute area is updated. Select Tools > Signal Engineering from the menu bar to see the signal information of the selected station. This operation opens the station Configuration page. You can manage the signals with Add, Edit and Delete buttons in the Configuration page. Signal items can be edited only when the System Configuration Tool is in offline mode. In online mode the buttons Add, Edit and Delete are disabled and the signal configuration can be viewed but not modified.
Add/Edit
Add and Edit buttons open the signal Add/Edit dialog for entering or changing the signal information. The user interface of this dialog depends on the station type.
OK
The OK button accepts the entered values into the signal list of the device and closes the Add/Edit dialog.
Cancel
The Cancel button cancels the add/edit operation and closes the Add/Edit dialog.
Apply
The Apply button accepts the entered values into the signal list without closing the dialog.
*
When a device configuration tool is closed, the signals related to the selected device are transferred to the System Configuration Tool. When Configuration > Save Active is selected, these signals are saved into the configuration files and they become a part of the configuration data. The device signals are interpreted automatically when the NET communication is starting. You can see the SCIL commands which are created from the device signals by selecting Configuration > Preview from the System Configuration Tool menu bar.
180
1MRS756112
To edit the signal information, follow the steps given below: 1. In the Object Tree, select the station to be engineered. 2. Select Tools > Signal Engineering from the menu bar, as shown in Fig. 4.1.15.1.-2. The station configuration page opens for editing.
A060291
Fig. 4.1.15.1.-2
4.1.15.2.
4.1.15.3.
181
1MRS756112
A060292
Fig. 4.1.15.3.-1
The topic information of a PLC station in the Advanced page of the System Configuration Tool
To add a new topic item, click the Add button, which opens the Add Topic Item dialog, as shown in Fig 4.1.15.3.-2. In this dialog, the default topic type is object command or the type of the last added topic item. The maximum number of topic items for each device is 100. If the station already includes 100 topic items, the Add button is disabled.
A060299
Fig. 4.1.15.3.-2
182
1MRS756112
To delete existing topic items, select the appropriate item in the list and click the Delete button. Before the deletion is done, a notification dialog is displayed to the user. Clicking Yes deletes the selected topic item and refreshes the list. Clicking No cancels the delete operation. To edit an existing topic item, select the appropriate topic item in the list and click the Edit button. Editing can also be done by double-clicking the topic item. The selected topic items are displayed in the Topic Configuration Editor with the existing definitions, as shown in Fig 4.1.15.3.-3. In this dialog, the topic type, allocation, first object address, last object address, base address, format, interval and deadband are defined.
A060300
Fig. 4.1.15.3.-3
With indication type, one object address (OA) contains 16 bits and it includes both single and double indications.
Allocation
This item specifies whether the topic is in use or not. The memory needed for the topic is reserved, when the topic is taken into use. Values: Enabled or disabled.
183
1MRS756112
Base Address
Base Address specifies the address of first item of topic in the device's memory. Values: 0 65535.
Format
Format specifies how the data is stored in an external device.
Interval
Interval specifies the frequency that the data of topic is read from an external device. The interval units are milliseconds. If the interval is 0, the topic is not polled. Values: 0 65535.
Deadband
If the type of topic is an analog value, then the Deadband value is used to minimize the amount of updating messages from the PC-NET to the base system. The new analog value is sent to the base system, when the change or sum (integral) of changes is bigger than the deadband. Values: 0 65535.
4.1.15.4.
184
1MRS756112
A060304
Fig. 4.1.15.4.-1
The data point configuration of DNP station in the Advanced page of the System Configuration Tool
To add a new item, click the Add button. This action opens the Add Data Point Item dialog. In this dialog, the default type is event poll. If the DNP station already contains the defined event poll item, the default type is always freely defined poll. If DNP station already includes the maximum number of data point items, the Add button is disabled, as there may be maximum fifty freely defined data point items for one DNP device. To delete the existing data point items, select the appropriate item in the list and click Delete. Before the delete operation is done, a notification dialog is displayed to the user. Click Yes to delete the selected data point item and refreshes the list. Click No to cancel the deletion. To edit the existing data point item, select the appropriate item in the list and click Edit or double-click the data point item. The selected items are displayed in the Data Point Configuration Editor with the existing definitions, as shown in Fig 4.1.15.4.-2. In this dialog, the poll type, polling interval, object, variation, description, number of events and lower/upper limit of index range are defined.
185
1MRS756112
A060306
Fig. 4.1.15.4.-2
Poll Type
Pole Type specifies the poll type of a data point item. There may be one event poll and maximum 50 freely defined polls for a DNP station.
Polling Interval
Polling Interval specifies the polling interval as seconds. Setting this parameter to zero stops the poll, which is the default for freely defined poll. For event poll, the default is 100.
Number of Events
Number of Events specifies the number of events to be polled. Value 0 indicates that all events are to be polled. Default value is 0.
186
1MRS756112
4.1.15.5.
A060301
Fig. 4.1.15.5.-1
The memory area configuration of STA station in the Advanced page of the System Configuration Tool
To add a new item, click the Add button, which opens the Add Memory Area Item dialog as shown in Fig 4.1.15.5.-2. In this dialog, the default type is binary input or the type of the last added item. If STA station already includes 30 items, the Add button is disabled, as the maximum number of the memory area items for each STA device is 30.
187
1MRS756112
A060302
Fig. 4.1.15.5.-2
New memory area item, Binary Input, is added to the STA station
To delete the existing memory area items, select the appropriate item in the list and click Delete. Before the deletion is done, a notification dialog is displayed to the user. Click Yes to delete the selected memory area item and refreshes the list. Click No cancel the delete operation. To edit the existing memory area item select the appropriate item in the list and click Edit or double-click the memory area item. The selected items are displayed in the Memory Area Configuration Editor with the existing definitions, as shown in Fig 4.1.15.5.-3. In this dialog, the data type, coding, start address, length, access type, block format, time stamp and split destination are defined.
188
1MRS756112
A060303
Fig. 4.1.15.5.-3
Data Type
Data Type specifies the data type of process objects. The following data types of STA device are available: Binary Input, Binary Output, Analog Input, Analog Output, Transparent and Time Sync Data.
Coding
Coding specifies the coding of the data elements in the address interval defined by the memory area. The value of CO attribute tells the communication program how to interpret the data of the memory area. Values: 1 - 8 Bit Binary Value 2 - 12 Bit Binary Value 3 - 16 Bit Binary Value 4 - 32 Bit Binary Value 5 - 3 Digit BCD Value 6 - 4 Digit BCD Value
189
1MRS756112
7 - Not in Use 8 - Not in Use 9 - 32 Bit Floating Point Value 10 - ASCII Data 11 - 16 Bit Integer Value 12 - 32 Bit Integer Value
Start Address
Start Address specifies the word address of the first words memory area. Value range: 0 - 32767.
Length
Length specifies the number of words in the memory area. Value range: 0 - 32767.
Access Type
Access Type defines whether the write commands directed to this memory area are protected or unprotected. The attribute is relevant only to Allen Bradley stations. Values: 0 = Unprotected 1 = Protected
Block Format
Block Format states if the spontaneous command messages from the station use the basic format of the protocol, or if an additional address field is used. Values: 1 = Basic Allen-Bradley 2 = Special 1 (the message contains a second word address, which is a BCD coded octal number) 3 = Special 2 (the message contains a second, binary word address) 4 = Multi-Event Transmission (allows transmission of many events with noncontinuous addresses in the same telegram)
190
1MRS756112
Time Stamp
Time Stamp states whether the time tagged information is included in spontaneous commands from the station. Values: 0 = No Time Stamp 1 = Time Stamp
4.2.
Recognizing of the base system objects in SYS 600 system Viewing of the base system related attributes and their values Editing of the base system object related attribute values Adding of base system objects
For further information about Base System Object Navigator, refer to the System Objects manual. As the tool is an online tool, the modified attribute values or added base system objects affect only the running system. If there is need to configure the system permanently, the changes should be made to base system configuration files (SYS_BASCON.COM).
4.3.
4.3.1.
191
1MRS756112
4.3.2.
Configuring objects
For each object found in the object tree, there are set of properties that can be adjusted by using Object Properties of CET. In this way, the communication details, such as IP Address of the Communication Port for IEC61850 Subnetwork can be set. Refer to the MicroSCADA Pro IEC 61850 Master Protocol manual for further details of configuring object properties.
4.3.3.
192
1MRS756112
5.
Abbreviations
Abbreviation IP SCIL WAN Description Internet protocol Supervisory Control Implementation Language Wireless network
193
ABB Oy Substation Automation Products P.O. Box 699 FI-65101 Vaasa FINLAND +358 10 2211 +358 10 224 1094 www.abb.com/substationautomation
1MRS756112 EN 12/2007