E-Terracontrol 3.9 Reference Manual - Interfaces To External Systems

e-terracontrol Reference Manual:
Interfaces to External Systems
This document provides configuration and modeling information about the interfaces to
external systems that are provided with e-terracontrol.
Software Version: e-terracontrol 3.9

Document Date: December 9, 2015
Copyright and Proprietary Information
Copyright © 2015 ALSTOM Grid Inc. or Affiliate. All Rights Reserved.
NOTE: CONTAINS PROPRIETARY INFORMATION OWNED BY ALSTOM GRID INC. AND/OR ITS
AFFILIATES. DO NOT COPY, STORE IN A RETRIEVAL SYSTEM, REPRODUCE, DISTRIBUTE,
TRANSMIT OR DISCLOSE TO ANY THIRD PARTY WITHOUT PRIOR WRITTEN PERMISSION FROM
ALSTOM GRID INC.
__________________________________________________________________
Trademarks
“ESCA” and “HABITAT” are registered trademarks of ALSTOM Grid Inc. “eterra” is a registered
trademark and/or service mark of E-Terra, LLC, licensed for use by ALSTOM Grid Inc. in connection with
its e-terra family of products and services.
Other product and company names in these materials may be trademarks or registered trademarks of
other companies, and are the property of their respective owners. They are used only for explanation and
to the respective owners’ benefit, without intent to infringe.
Contents
About This Document ............................................................................................... ix
Purpose of This Document ............................................................................................ ix
Who Should Use This Document .................................................................................. ix
Structure of This Document .......................................................................................... ix
For More Information..................................................................................................... x
Document Conventions ................................................................................................ xii
Change Summary ....................................................................................................... xiii
1. Overview ................................................................................................................. 1
1.1 Status Point History ................................................................................................. 2
2. ADO/SMP Interface Application ............................................................................ 3

2.1 ADO/SMP Command-Line Argument ...................................................................... 3
2.2 Starting the ADO/SMP Interface Using the Process Starter .................................... 3
2.3 ADO/SMP Interface Application User Interface ....................................................... 4
2.4 ADO/SMP Interface Menu Bar ................................................................................ 5
2.4.1 ADO/SMP Interface Debug Output Window....................................................... 5
2.5 ADO/SMP Interface Configuration File Format ....................................................... 6
2.5.1 ADO/SMP Interface Configuration File Example .............................................. 10
3. DDEML/SMP Interface Application ..................................................................... 12

3.1 DDEML/SMP Interface User Interface .................................................................. 13
3.2 DDEML/SMP Interface Menu Bar ......................................................................... 13
3.3 DDEML/SMP Interface Debug Output Window ..................................................... 14
3.4 DDEML/SMP Interface Configuration File Format................................................. 14
3.4.1 DDEML/SMP Interface Configuration File Example ......................................... 20
3.5 DDE Simulation Program ...................................................................................... 21
4. InterSite Data Application .................................................................................... 23

4.1 InterSite Data Command-Line Arguments ............................................................ 23
4.2 InterSite Data User Interface ................................................................................. 24
4.3 InterSite Data Menu Bar ........................................................................................ 26
4.4 ISD Diagnostics Dialog Box .................................................................................. 26
4.5 User and Area Permissions................................................................................... 26
5. Modbus/SMP Interface Application .................................................................... 28

5.1 Modbus/SMP Command-Line Argument ............................................................... 28
5.2 Starting the Modbus/SMP Interface Using the Process Starter ............................. 28
5.3 Modbus/SMP Interface User Interface .................................................................. 29
5.4 Modbus/SMP Interface Menu Bar ......................................................................... 30
5.5 Modbus/SMP Interface Debug Output Window ..................................................... 31
5.6 Modbus/SMP Interface Configuration File Format ................................................ 31
5.6.1 Modbus/SMP Interface Configuration File Example ......................................... 36
Proprietary – See Copyright Page iii

6. OPC DA Server Application ................................................................................. 39
6.1 OPC DA Server Command-Line Arguments ......................................................... 39
6.1.1 Configuration File Name .................................................................................. 39
6.1.2 Data Source Name .......................................................................................... 41
6.2 Starting the OPC DA Server Using the Process Starter ........................................ 41
6.3 OPC DA Server Installation ................................................................................... 42
6.3.1 DCOM Configuration ........................................................................................ 42
6.4 OPC DA Server User Interface ............................................................................. 46
6.4.1 OPC DA Server Main Window ......................................................................... 47
6.4.2 Configuration Dialog Box ................................................................................. 48
6.5 Data Source and Data Set Configuration .............................................................. 49
6.5.1 Data Source ..................................................................................................... 49
6.5.2 Data Sets ......................................................................................................... 49
6.6 OPCServer Single Instance .................................................................................. 49
6.7 Configuration Settings for Connecting OPCClient with a Remote OPC DA Server50
6.8 OPCServer and Multiple Scada Instance .............................................................. 51
7. PI/SMP Interface Application ............................................................................... 52

7.1 PI/SMP Command-Line Argument ........................................................................ 52
7.2 Starting the PI/SMP Interface Using the Process Starter ...................................... 53
7.3 PI/SMP Interface User Interface............................................................................ 54
7.4 PI/SMP Interface Menu Bar................................................................................... 54
7.5 PI/SMP Interface Debug Output Window .............................................................. 55
7.6 PI/SMP Interface Configuration File Format .......................................................... 55
7.6.1 PI/SMP Interface Configuration File Example .................................................. 60
8. ICCP Application .................................................................................................. 61

9. XX/SMP Interface Application ............................................................................. 62
9.1 Command-Line Arguments ................................................................................... 62
9.1.1 Command-Line Arguments Quick Reference................................................... 63
9.1.2 SCADA Connection Timeout............................................................................ 64
9.1.3 Startup Delay ................................................................................................... 64
9.1.4 Configuration Check......................................................................................... 65
9.1.5 Controls Response .......................................................................................... 65
9.1.6 Configuration Data Source Mode – Data Set ................................................... 65
9.1.7 Engineering Unit Value Display Format ........................................................... 66
9.1.8 Configuration File Name (Deprecated)............................................................. 66
9.1.9 Reference Name for Points .............................................................................. 66
9.1.10 Log Box Diagnostic Message Level ............................................................... 67
9.1.11 Log File Diagnostic Message Level ............................................................... 67
9.1.12 Adding Measurements to Diagnostics Window .............................................. 68
9.1.13 Configuration Data Source Mode – Measurement Tree (Deprecated) ........... 68
9.1.14 Data Source Name (REQUIRED) .................................................................. 69
9.1.15 Measurement Write Timeout .......................................................................... 69
9.1.16 Change-of-State Notification – Passive.......................................................... 69
9.1.17 Quality Ignore ................................................................................................. 69
Proprietary – See Copyright Page iv

9.1.18 Raw Values (Deprecated) .............................................................................. 70
9.1.19 Synthesized Values (Deprecated) .................................................................. 70
9.1.20 Log File Rollover Size .................................................................................... 70
9.1.21 Configuration Data Source Mode – Text File (Deprecated) ........................... 71
9.1.22 Change-of-State Notification Source – Unsolicited ........................................ 71
9.1.23 e-terracontrol Version .................................................................................... 72
9.1.24 Allow Remote Exit Command ........................................................................ 72
9.1.25 Log File Folder ............................................................................................... 72
9.1.26 Host(s) Arguments ......................................................................................... 73
9.1.27 SCADA Port ................................................................................................... 73
9.1.28 SCADA Database Name ................................................................................ 73
9.2 User Interface........................................................................................................ 73
9.2.1 Main Window ................................................................................................... 74
9.2.1.1 ProtocolPak Status Messages .................................................................... 74
9.2.1.2 Menu Bar .................................................................................................... 75
9.2.1.2.1 Log Menu ............................................................................................... 75
9.2.1.2.2 Tools Menu ............................................................................................ 75
9.2.1.2.3 Security Menu ........................................................................................ 76
9.2.1.2.4 Debug Menu .......................................................................................... 76
9.2.1.2.5 Help Menu ............................................................................................. 77
9.2.2 Diagnostics Window ......................................................................................... 78
9.2.3 Security Configuration Windows ...................................................................... 81
9.2.4 Window Position and Sizing ............................................................................. 81
9.3 xx2smp Log Files .................................................................................................. 81
9.3.1 xx2smp Log File Rollover ................................................................................. 82
9.4 ProtocolPak Log Files ........................................................................................... 83
9.4.1 ProtocolPak Log File Rollover .......................................................................... 84
9.4.2 Searching for Errors in ProtocolPak Log Files ................................................. 84
9.5 ProtocolPak Connection Status Indicator .............................................................. 85
9.5.1 Serial Communications .................................................................................... 86
9.5.2 Network Communications ................................................................................ 88
9.5.3 Display Indications ........................................................................................... 88
9.5.4 Database Storage of Indicators ........................................................................ 89
9.5.5 Examples and Operational Notes .................................................................... 89
9.6 Data Source Configuration (Measurements) ......................................................... 90
9.7 Data Set Configuration .......................................................................................... 92
9.7.1 xx2smp Data Set Types ................................................................................... 94
9.7.1.1 xx2smpDS Data Set Type ........................................................................... 94
9.7.1.2 xx2smpDS_Status Data Set Type............................................................... 95
9.7.1.3 xx2smpMasterDS Data Set Type ................................................................ 96
9.7.1.4 xx2smpCommsDS Data Set Type .............................................................. 97
9.7.1.5 StatusDS Data Set Type ............................................................................. 98
9.7.2 xx2smp Data Set .............................................................................................. 99
9.7.3 xx2smp Master Data Set .................................................................................. 99
9.7.4 xx2smp Comms Data Set .............................................................................. 107
9.7.4.1 DNP Parameters ....................................................................................... 115
Proprietary – See Copyright Page v

9.7.4.2 IEC101/104 Parameters ........................................................................... 130
9.7.4.3 Telegyr 8979 Parameters ......................................................................... 146
9.7.5 RTU Data Set ................................................................................................. 149
9.7.6 ScanGroup Data Set ...................................................................................... 151
9.7.7 Card Data Set ................................................................................................ 157
9.7.7.1 Object Mapping Restrictions ..................................................................... 163
9.7.7.2 IEC Object Support Notes ......................................................................... 166
9.7.7.3 Data Items ................................................................................................ 167
9.7.8 PseudoCard Data Set .................................................................................... 167
9.7.9 Security Data Set ........................................................................................... 169
9.7.10 Security Alarms Data Set ............................................................................. 171
9.7.11 Security Alarms Statuses Data Set .............................................................. 172
9.7.12 xx2smp Status Data Set Tree ...................................................................... 173
9.7.13 Root Status Data Set ................................................................................... 173
9.7.14 Status Data Set ............................................................................................ 174
9.7.15 Mapping Data Set States Through Data Items............................................. 176
9.8 Text File Configuration ........................................................................................ 178
9.9 Measurement Mode Configuration ...................................................................... 178
9.10 Sample Databases ............................................................................................ 179
9.11 Control Response Notifications ......................................................................... 179
9.12 Protocol-Specific e-terracontrol Quality Mapping.............................................. 181
9.12.1 DNP Quality Mapping................................................................................... 182
9.12.1.1 Status Objects......................................................................................... 182
9.12.1.2 Analog Objects........................................................................................ 183
9.12.1.3 Accumulator Objects ............................................................................... 183
9.12.2 IEC Quality Mapping .................................................................................... 184
9.12.2.1 Status Objects......................................................................................... 184
9.12.2.2 Analog Objects........................................................................................ 185
9.12.2.3 Accumulator Objects ............................................................................... 186
9.12.3 Telegyr 8979 Quality Mapping ..................................................................... 186
9.13 Troubleshooting Network Data Transmission.................................................... 187
9.14 Interoperability Information ................................................................................ 187
9.14.1 DNP Device Profile ...................................................................................... 187
9.14.2 IEC101 Interoperability................................................................................. 196
9.14.2.1 System or Device .................................................................................... 196
9.14.2.2 Network Configuration (Network-Specific Parameter)............................. 196
9.14.2.3 Physical Layer (Network-Specific Parameter) ......................................... 197
9.14.2.4 Link Layer (Network-Specific Parameter) ............................................... 197
9.14.2.5 Application Layer .................................................................................... 198
9.14.2.6 Selection of Standard ASDUs ................................................................. 199
9.14.2.7 Basic Application Functions .................................................................... 204
9.14.3 IEC104 Interoperability................................................................................. 208
9.14.3.1 System or Device .................................................................................... 209
9.14.3.2 Network Configuration (Network-Specific Parameter)............................. 209
9.14.3.3 Physical Layer (Network-Specific Parameter) ......................................... 209
9.14.3.4 Link Layer (Network-Specific Parameter) ............................................... 209
Proprietary – See Copyright Page vi

9.14.3.5 Application Layer .................................................................................... 209
9.14.3.6 Selection of Standard ASDUs ................................................................. 210
9.14.3.7 Basic Application Functions .................................................................... 215
9.14.4 Telegyr 8979 Interoperability........................................................................ 219
Figures
Figure 1. ADO/SMP Interface User Interface Window..................................................... 4
Figure 2. ADO/SMP Debug Output Window.................................................................... 5
Figure 3. DDEML/SMP Interface Window ..................................................................... 13
Figure 4. DDEML/SMP Interface Debug Output Window .............................................. 14
Figure 5. Test DDE Application – wwwdde ................................................................... 22
Figure 6. Test DDE Setpoint Window ............................................................................ 22
Figure 7. InterSite Data User Interface Window ............................................................ 24
Figure 8. ISD Diagnostics Dialog Box ........................................................................... 26
Figure 9. Modbus/SMP Interface User Interface Window.............................................. 29
Figure 10. Modbus/SMP Debug Output Window ........................................................... 31
Figure 11. OPC DA Server Main Window ..................................................................... 47
Figure 12. OPC DA Server Configuration Dialog Box ................................................... 48
Figure 13. PI/SMP Interface User Interface Window ..................................................... 54
Figure 14. PI/SMP Debug Output Window .................................................................... 55
Figure 15. xx2smp Main Window .................................................................................. 74
Figure 16. xx2smp Diagnostics Window........................................................................ 78
Figure 17. xx2smp Data Source Example ..................................................................... 91
Figure 18. xx2smp Data Source Example ..................................................................... 92
Figure 19. xx2smp Data Set Hierarchy.......................................................................... 93
Figure 20. xx2smpDS Data Set Type Example ............................................................. 94
Figure 21. xx2smpDS_Status Data Set Type Example ................................................. 95
Figure 22. xx2smpMasterDS Data Set Type Example .................................................. 96
Figure 23. xx2smpCommsDS Data Set Type Example ................................................. 97
Figure 24. StatusDS Data Set Type Example ............................................................... 98
Figure 25. xx2smp Data Set Example ........................................................................... 99
Figure 26. xx2smp Master Data Set Example ............................................................... 99
Figure 27. xx2smp Comms Data Set Example ............................................................ 107
Figure 28. RTU Data Set Example .............................................................................. 149
Figure 29. ScanGroup Data Set Example ................................................................... 151
Figure 30. Card Data Set Example ............................................................................. 157
Figure 31. PseudoCard Data Set Example ................................................................. 167
Figure 32. Security Data Set Example ........................................................................ 169
Figure 33. Security Alarms Data Set Example ............................................................ 171
Figure 34. Security Alarms Statuses Data Set Example ............................................. 172
Figure 35. Root Status Data Set Example................................................................... 173
Figure 36. Status Data Set Example ........................................................................... 174
Figure 37. Typical Status Data Set Data Items ........................................................... 175
Figure 38. DNP Device Profile Document ................................................................... 192
Proprietary – See Copyright Page vii

Tables
Table 1. e-terracontrol Interface Applications Data Mapping with External Systems ...... 1
Table 2. Defined Resources for the ADO/SMP Interface ................................................ 6
Table 3. Item Definition for the ADO/SMP Interface ........................................................ 8
Table 4. Defined Resources for the DDEML/SMP Interface.......................................... 15
Table 5. Item Definition for the DDEML/SMP Interface ................................................. 16
Table 6. Defined Resources for the Modbus/SMP Interface ......................................... 32
Table 7. Item Definition for the Modbus/SMP Interface ................................................. 32
Table 8. Default Values of the Configuration Parameters ............................................. 40
Table 9. Defined Resources for the PI/SMP Interface ................................................... 56
Table 10. Item Definition for the PI/SMP Interface ........................................................ 57
Table 11. xx2smp Command-Line Arguments Quick Reference ................................... 63
Table 12. ProtocolPak Status Log Messages ................................................................ 75
Table 13. DNP Parameters Quick Reference .............................................................. 115
Table 14. ProtocolPak DNP Default Variations ........................................................... 123
Table 15. IEC Parameters Quick Reference ............................................................... 130
Table 16. ProtocolPak IEC Object Array Defaults ....................................................... 145
Table 17. Telegyr 8979 Parameters Quick Reference ................................................ 146
Table 18. Telegyr 8979 Card Codes and Card Sizes .................................................. 148
Table 19. DNP Object Mapping Restrictions ............................................................... 164
Table 20. IEC Object Mapping Restrictions................................................................. 164
Table 21. Telegyr 8979 Object Mapping Restrictions .................................................. 166
Table 22. DNP Status Objects Quality Mapping .......................................................... 182
Table 23. DNP Analog Objects Quality Mapping ......................................................... 183
Table 24. DNP Accumulator Objects Quality Mapping ................................................ 183
Table 25. IEC Status Objects Quality Mapping ........................................................... 184
Table 26. IEC Analog Objects Quality Mapping .......................................................... 185
Table 27. IEC Accumulator Objects Quality Mapping.................................................. 186
Table 28. DNP Device Profile ...................................................................................... 192
Table 29. Telegyr 8979 Supported Function Codes .................................................... 219
Proprietary – See Copyright Page viii

About This Document
This document is supplied as a part of Alstom Grid’s e-terracontrol product.
Purpose of This Document

This document is intended for use as follows:
• To introduce the reader to the e-terracontrol applications
• To provide configuration and modeling information about the interfaces to external
systems provided with e-terracontrol
Who Should Use This Document

This document is intended for all users of e-terracontrol.
Structure of This Document

This document is structured in the following manner:
• Chapter 1 provides a brief overview of the interfaces to external systems provided
with e-terracontrol.
• Chapter 2 provides modeling and configuration information about the ADO/SMP
interface application.
• Chapter 3 provides modeling and configuration information about the DDEML/SMP
• Chapter 4 provides modeling and configuration information about the InterSite Data
application.
• Chapter 5 provides modeling and configuration information about the Modbus/SMP
• Chapter 6 provides modeling and configuration information about the OPC DA
server application.
• Chapter 7 provides modeling and configuration information about the PI/SMP
• Chapter 8 provides modeling and configuration information about the ICCP
application.
• Chapter 9 provides modeling and configuration information about the XX/SMP
Proprietary – See Copyright Page ix

For More Information
For more information about configuring and modeling e-terracontrol, refer to the
following:
• e-terracontrol Reference Manual: Introduction and Configuration – Features non-
specific application configuration issues such as client-server architecture,
redundancy, and line switching.
• e-terracontrol Reference Manual: Applications – Describes the modeling and
configuration activities for the principal applications: SCADA Server and Process
Starter; and the ancillary applications: Alarm Logger, Alarm Pager, Automatic
Database Update, Change Data Source, Copy History, Space Saver, and Validator.
• e-terracontrol Reference Manual: User Interface Applications – Features the
applications designed to present information. These applications include
Measurement History, Sequence of Events (Compiler and Viewer), Simulator, SMP
Display Linker, Virtual Charts, and Alarm Viewer.
• e-terracontrol Reference Manual: Interfaces to Field Devices – Features
applications designed to retrieve measurements from field devices such as Remote
Terminal Units (RTUs), Programmable Logic Controllers (PLCs), and Intelligent
Electrical Devices (IEDs). These applications include CFE Reader, CFE
Performance Driver, OPC DA Client, PLC Reader (Modbus Reader and TI Reader),
TrueTime Reader, and Relay Reader.
For more information about e-terracontrol in general, refer to the following:
• e-terracontrol Release Notes
• e-terracontrol Programmer’s Guide – Describes the interfaces that allow external
processes to communicate with e-terracontrol.
• e-terracontrol Protocol Modeling Guide – Provides modeling details for the
e-terracontrol protocol implementations that are supported in the CFE Reader
application.
• e-terracontrol Display Builder Guidelines – Explains the features and capabilities of
e-terracontrol–based e-terrabrowser displays. It should be helpful to anyone
seeking to build e-terracontrol displays.
For more information about e-terrabrowser, refer to the following:
• e-terrabrowser Software Installation and Maintenance Guide – Provides information
about and instructions for the configuration of the e-terrabrowser Viewer application.
• e-terrabrowser User’s Guide – Provides a guide to the use of e-terrabrowser, the
Web technology–based version of e-terrahabitat’s user interface processor and
command language.
Proprietary – See Copyright Page x

For more information about designing displays for viewing in e-terrabrowser, refer to the
following:
• Display Builder User’s Guide – An introduction to the concepts, features, and
components of the Display Builder software. Instructions for how to use the Display
Builder software to build displays and how to define display components for viewing
in e-terrabrowser.
For more information about the e-terracontrol/ICCP application, refer to the following:
• e-terracontrol/ICCP User’s Guide, Modeling – Provides instructions for the modeling
of the e-terracontrol/ICCP application.
• e-terracontrol/ICCP User’s Guide, Real-Time Operation – Provides information
about and instructions for the operation of the e-terracontrol/ICCP application.
• e-terracontrol/ICCP Release Notes
For more information about RTUMMU, refer to the following:
• RTU Miscellaneous Message Utility User’s Guide – Details use and user notes for
the Remote Terminal Unit Miscellaneous Messages Utility (RTUMMU).
For more information about security configuration aspects for the XX/SMP interface
application, refer to the following:
• ProtocolPak Security Configuration User’s Guide – Provides information about the
configuration of the xx2smp application for use in secure networks.
Proprietary – See Copyright Page xi

Document Conventions
The following conventions are used throughout this document. Commands that are
particular to an operating system are shown with the corresponding prompt symbol.
Command Prompts
Operating Prompt Description
System
Linux % All commands preceded by a percent sign prompt
(%) are issued from a Linux terminal window. Note
that all Linux commands are case sensitive.
Windows > All commands preceded by a greater than sign
prompt (>) are issued from a Windows command
line window.
All Operating The absence of any prompt character before a
Systems command indicates that the command is valid on
all operating systems.
Command Strings
Operating Delimiter Description
System
Linux Italics Text in italics indicates information you must
supply. (*)
Linux [] Text enclosed in square brackets "[ ]" indicates
optional qualifiers, arguments, or data. (*)
All Operating Select When used in command strings, the term “Select”
Systems means placing the pointer over the specified item
and pressing the left (default) mouse button.
(*) Note: All Linux commands are case sensitive and must be typed exactly as
shown.
Proprietary – See Copyright Page xii

Change Summary
The following changes were made to this document for e-terracontrol 3.9:
• Added a description of ScadaSdbName in Table 4. Defined Resources for the
DDEML/SMP Interface.
• Updated the code example in section 3.4.1 DDEML/SMP Interface Configuration File
Example.
• Added section 6.8 OPCServer and Multiple Scada Instance.
• Added sdb to Table 11. xx2smp Command-Line Arguments Quick Reference.
• Added section 9.1.28 SCADA Database Name.
Proprietary – See Copyright Page xiii

1. Overview
e-terracontrol includes an application, “XX/SMP”, that provides an interface to the
SCADA database for master, or client, systems. This application interfaces to traditional
master/client systems, where measurements are transferred from e-terracontrol to the
master/client system, and where setpoints and controls are accepted into e-terracontrol
from the master/client system.
It is important to note that this application can also accept measurements from the
master/client into e-terracontrol.
e-terracontrol also includes applications such as ADO/SMP, DEML/SMP, Modbus/SMP,
and PI/SMP, which all interface with remote systems, where measurements and
setpoints are transferred from e-terracontrol to a remote system and where
measurements are accepted into e-terracontrol from the remote system.
The InterSite Data application is also included in e-terracontrol. This application is used
to exchange (send and/or receive) data between Alstom Grid systems, such as
e-terracontrol and e-terraplatform. Table 1 summarizes the data exchanged between
the e-terracontrol interface applications and the external systems.
The OPC DA server application is a server designed to communicate with OPC clients.
Finally, the e-terracontrol/ICCP application is an optional e-terracontrol application that
allows data exchange between the SCADA server and remote partners using the ICCP
protocol (also known as “TASE.2”).
Table 1. e-terracontrol Interface Applications Data Mapping with External Systems

Analogs Statuses Accumulators Setpoints Controls
In Out In Out In Out In Out In Out
XX/SMP Yes Yes Yes Yes Yes Yes Yes No Yes No
ADO/SMP Yes Yes Yes Yes No No No Yes No No
DDEML/SMP
Modbus/SMP
PI/SMP
InterSite Data Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
e-terracontrol
/ICCP
Proprietary – See Copyright Page 1 Overview

e-terracontrol Reference Manual: Interfaces to External Systems
1.1 Status Point History
Typically, it is a requirement of slave applications to provide all status point changes to
the master. This means that applications such as ISD and xx2smp need to be aware of
not only the status point value at the time that it is refreshed, but also any inter-refresh
changes of state.
For example, if the SCADA server is configured for a two-second default refresh,
xx2smp is refreshed with the new status point values every two seconds. However, if a
breaker trips and then recloses in that two-second span, the slave application typically
needs to be aware of the trip, as well as the subsequent close.
The buffering of status point history can be enabled by toggling ON the Keep History
flag on the Status Type (for more information, see the section on the Status Type dialog
box in the e-terracontrol Reference Manual: Applications).
Proprietary – See Copyright Page 2 Overview

2. ADO/SMP Interface Application
The ado2smp application transfers data from a Microsoft ActiveX Data Objects (ADO)
database to the e-terracontrol database, and it transfers setpoints, analogs, and digitals
from the e-terracontrol database to the ADO database.
The ado2smp application transfers data from the Microsoft ActiveX Data Objects (ADO)
database to the e-terracontrol database if the following conditions are satisfied:
• The data source mentioned in the configuration file entry “ScadaSource” is defined
in the SCADA database.
• In the SCADA database, the mentioned data source is assigned to the measurement
points that are configured in the configuration file with type as “Analog” or “Digital”.
2.1 ADO/SMP Command-Line Argument

An ado2smp shortcut is not created during the installation of e-terracontrol, because
there is an optional command-line argument associated with this application. The
application can be launched from the Process Starter, a command line, a batch file, or a
Windows shortcut created with the appropriate command-line arguments included.
The ado2smp application reads the default configuration file “ado2smp.txt” from the
application directory path. The file name can also be passed in as a command-line
argument. If the file cannot be found, the application does not run.
An example command-line statement is:
~\ado2smp D:\ADO_Files\ado2smp.txt
2.2 Starting the ADO/SMP Interface Using the Process Starter

The Process Starter application (see “Process Starter” in the e-terracontrol Reference
Manual: Applications) has the ability to start and restart programs as required. This is
useful in situations where it is desired that the ADO/SMP interface application remain
continuously active on certain PCs.
1. From the e-terracontrol Start menu, open the Process Starter console application,
and be sure that the Process Starter service is running.
2. Connect the console to the Process Starter service by clicking the Connect button in
the Process Starter console toolbar.
3. To create a new Process Starter group, proceed to step 4. To add the ADO/SMP
interface to an existing group, select File > Upload, and choose the desired .psc file
to display the Configuration tab for Processes.
Note: Prior to adding a process to an existing group, you must end all processes
by clicking Stop on the Process Starter toolbar or via the Actions menu item (see
Proprietary – See Copyright Page 3 ADO/SMP Interface Application

“Process Starter Console Toolbar” and “Process Starter Console Menu Bar” in the
e-terracontrol Reference Manual: Applications).
4. To create a new Process Starter group, select Processes > Add Process.
The Configuration tab for Processes opens.
5. In the Name, Program, Params, and Directory text boxes, enter the required
information.
If you do not know the location of the ado2smp.exe file, click the Ellipsis button (...)
next to the Program text box to browse for the file. Sample values are as follows:
Name: ADO/SMP Interface
Program: C:\eterra\e_terracontrol\bin32\ado2smp.exe
Params (Optional): D:\ADO_Files\ado2smp.txt
Directory:
6. If desired, select the Minimize check box.
7. If you do not want to see the GUI, uncheck the Visible check box.
8. In the Restart frame, select the On Exit radio button.
9. Click OK.
10. Save the file.
2.3 ADO/SMP Interface Application User Interface
Figure 1. ADO/SMP Interface User Interface Window

The following are included in the ADO/SMP Interface user interface window:
Header
• Time: Current local time in 24-hour clock format.
• Connect SCADA: Toggle ON to enable the SCADA connection.
• SCADA Update Time: Indicates the last time data was sent to SCADA.
View List
• SMP Point Name: These names match the device names of measurements in
SCADA.
• Tag Name: Identifier returned by the ADO query. Note that there can be more than
one SMP point name associated with a given tag; this allows separate digital type
SMP points to be driven by a single tag. This is useful when the tag returns a bit
mask containing several bits of information.
• Type: The type of point being processed.
• Value: Displays the value interpreted by the interface program from the query
results.
• Quality: Indicates the quality code for the point.
• Comment: Displays the comment associated with the point.
2.4 ADO/SMP Interface Menu Bar

The non-standard options on the menu bar are as follows:
Tools Menu
• Debug Output: Select to display the Debug Output window (Figure 2).
2.4.1 ADO/SMP Interface Debug Output Window
Figure 2. ADO/SMP Debug Output Window

The following are included in the Debug Output window:
• Limit Length to...MB: When checked, the amount of debug text displayed is limited
to the value entered in the adjacent text box in megabytes. This is also the maximum
size of individual log files, when the Log Errors in File check box is selected.
• Disable Output: Toggle ON to disable output messages.
• Log Errors in File: Toggle ON to save the messages generated to a file. Log files
are generated in the application directory path with the name
“ado2smp_yyyymmdd_hhmmss.log”, where yyyymmdd is the date and hhmmss is
the time.
2.5 ADO/SMP Interface Configuration File Format

Guidelines are as follows:
• Blank lines and lines beginning with “#” are ignored.
• Resource information can be set using the format:
ResourceName: Value
Where ResourceName is the case-sensitive resource name being set, and Value is
the value to which it is being set.
The resource name must be at the beginning of the line with no leading spaces. Do
not use quotation marks in the value string, even if spaces are significant. Spaces
between words are picked up literally, although trailing and leading spaces are
ignored.
Table 2. Defined Resources for the ADO/SMP Interface

Name Default Value Description
SmpPointNameWidth 1440 e-terracontrol point name column width
TagNameWidth 1440 Tag name column width
TypeWidth 1440 Type column width
ValueWidth 1440 Value column width
QualityWidth 1440 Quality column width
CommentWidth 1440 Comment column width
MainWidth 10755 Main window width
MainHeight 7950 Main window height
ScadaInterval 1000 Interval in milliseconds to send data to SCADA
ScadaSource TjrSrc The SCADA source name
ScadaPort 5020 or 7000 The SCADA server listening port (5020 for
NTLM/Kerberos authentication and 7000 for certificate-
based authentication)

Host1 localhost String specifying the host name for the SCADA
connection
Host2 String specifying the host name for the secondary SCADA
connection in a dual-state environment
Host3 String specifying the host name for the SCADA
connection
connection
StptFeedbckTime 4 Interval in seconds to feedback unit MW output to the unit
is setpoint when in local mode
LogErrors True Set to True if error messages should be output to a file
Access_Field_Style 1 Style to use when doing update request. If you are using a
Microsoft Access database, you should use this resource
and set it to 1. Otherwise, this resource must be set to 0.
DbName An ADO connection string must be provided. On Windows
XP machines, it is recommended to disable connection
pooling by adding the field “OLE DB SERVICES=-2”.
Otherwise, the database may not automatically reconnect
when the database server restarts.
AnalogQuery Analog SQL query
AnalogTag Analog tag field name
AnalogValue Analog value field name
AnalogQuality Analog quality field name
DigitalQuery Digital SQL query
DigitalTag Digital tag field name
DigitalStatus Digital status field name
SetpointTable Setpoint table name
SetpointTag Setpoint tag field name
SetpointValue Setpoint value field name
SetpointQuality Setpoint quality field name
AnalogOutTable Analog output table name
AnalogOutTag Analog output tag field name
AnalogOutValue Analog output value field name
AnalogOutQuality Analog output quality field name
DigitalOutTable Digital output table name
DigitalOutTag Digital output tag field name
DigitalOutStatus Digital output status field name

Each type of item has its own format. The first line defines the item type. Leading
spaces are removed and are optional.
Table 3. Item Definition for the ADO/SMP Interface

Definition Description
DIGITAL Digital point
SMP-Name e-terracontrol measurement device name
Tag Database tag name
Comment Comment field
StatusMask Mask (decimal) to AND with status field to get status
StatusClosed Value indicating close state, compared against status
BadMask Mask (decimal) to AND with status field to get bad quality
BadQuality Value indicating bad quality, compared against above result
OldMask Mask (decimal) to AND with status field to get old quality
OldQuality Value indicating old quality, compared against above result
ANALOG Analog point, puts engineering value
BadMask Mask (decimal) to AND with quality field to get bad quality
OldMask Mask (decimal) to AND with quality field to get old quality
ANARAW Analog point, puts raw value
SETPNT Setpoint
SMP-Name e-terracontrol setpoint measurement device name

STPTFB Setpoint with feedback
SMP-Name e-terracontrol setpoint measurement device name
RemoteLocalPoint Digital “SMP-Name” point, which indicates generator’s remote/local status
MwPoint Analog “SMP-Name” point, which indicates generator’s current MW
ANAOUT Analog output point, as engineering value
BadQuality Value indicating bad quality
GoodQuality Value indicating good quality
OldQuality Value indicating old quality
FreshQuality Value indicating fresh (not old) quality
ANARAWOUT Analog output point, as raw value
DIGOUT Digital output point
StatusClosed Value indicating close state

StatusOpen Value indicating open state
Note: If the point does not have a quality code, set the “mask” to 0 and the “quality” to
something non-zero, such as 1.
2.5.1 ADO/SMP Interface Configuration File Example

# SMP/Ado Interface Configuration File
# Resource Parameters:
ScadaSource: McmSrc
ScadaInterval: 4000
StptFeedbckTime: 120
DbName: XLTest1; OLE DB SERVICES=-2;
AnalogQuery: SELECT * FROM AnalogRange;
AnalogTag: Ndx
AnalogValue: AnalogVal
AnalogQuality: AnalogSts
DigitalQuery: Select * from DigitalRange;
DigitalTag: Ndx
DigitalStatus: Digital
AnalogOutTable: AnalogRange
AnalogOutTag: Ndx
AnalogOutValue: AnalogVal
AnalogOutQuality: AnalogSts
SmpPointNameWidth: 1400
TagNameWidth: 1100
TypeWidth: 1000
ValueWidth: 1200
QualityWidth: 1300
CommentWidth: 2400
MainWidth: 8800
MainHeight: 11000
Access_Field_Style: 1
ANAOUT
Brighton
BBR1_CNT
Test Output of Analog
Item2
0

2
0
DIGITAL
TestDigital1
Item1
Test Digital 1
2
2
0
1
0
1

3. DDEML/SMP Interface Application
The ddeml2smp application transfers data from a DDE server to the e-terracontrol
database, and it transfers setpoints from SCADA to the DDE server.
Dynamic Data Exchange Management Libraries (DDEML) is a Win API programmatic
alternative to the standard form-based DDE mechanisms provided by Microsoft
Visual Basic. This application supersedes the dde2smp application and includes several
enhancements.
The ddeml2smp interface supports both Request and Advise Loop transactions.
Request transactions are similar to Integrity transactions, where the data point is
reported whether or not its value has changed. Advise Loop transactions are similar to
Report-by-Exception transactions, where only data values that have changed since the
last scan are reported. When communication to the DDE server fails, the application
automatically tries to reconnect to the server at a specified interval (SrvConRetryTime).
A test DDE server program, “wwwdde”, is provided. This Visual Basic application
simulates the functionality of an actual DDE server.
The wwwdde application provides some simulation capability for frequency and
generation response to setpoint changes. Each unit has its own simulation enable
check box, with the frequency simulation function having its own simulation enable
check box as well. The tie line MW simulation is simply the net generation divided by
two for each line. The frequency is 60Hz plus the difference between scheduled and
actual interchange multiplied by the frequency sensitivity, plus an optional random noise
component.
The ddeml2smp application reads the default configuration file, “ddeml2smp.txt”, from
the application directory path. The file name can also be passed in as a command-line
The ddeml2smp application transfers data from a DDE server to the e-terracontrol
database if the following conditions are satisfied:
• The data source mentioned in the configuration file entry “ScadaSource” is defined
in the Scada database.
• In the Scada database, the mentioned data source is assigned to the measurement
points that are configured in the configuration file with type as “Analog” or “Digital”.
Proprietary – See Copyright Page 12 DDEML/SMP Interface Application

3.1 DDEML/SMP Interface User Interface
Figure 3. DDEML/SMP Interface Window
The following are included in the DDEML/SMP Interface user interface window:
• SMP Point Name: Displays the name of the data point as it appears in the
ddeml2smp.txt file.
• Value: Displays the value of the data point.
• Status: Displays the status of the data point.
• Quality: Displays the data quality of the data point.
• Comment: Displays a comment you have entered as it appears in the
ddeml2smp.txt file.
3.2 DDEML/SMP Interface Menu Bar

The non-standard Windows options on the menu bar are as follows:
Tools Menu
• Debug Output: Select to display the Debug Output window.
• Request: Select to enable Request transactions. Request transactions are similar to
Integrity transactions, where the data point is reported whether or not its value has
changed.
• Advise Loop: Select to enable Advise Loop transactions. Advise Loop transactions
are similar to Report-by-Exception transactions, where only data values that have
changed since the last scan are reported.

3.3 DDEML/SMP Interface Debug Output Window
Figure 4. DDEML/SMP Interface Debug Output Window
The following are included in the DDEML/SMP Interface Debug Output window:
to the value entered in megabytes in the adjacent text box. This is also the maximum
size of individual log files when the Log Errors in File check box is selected.
“ddeml2smp_yyyymmdd_hhmmss.log”, where yyyymmdd is the date and hhmmss is
the time.
3.4 DDEML/SMP Interface Configuration File Format

Settings are passed to the DDEML/SMP interface application through a configuration
text file. Guidelines are as follows:
ResourceName: Value
Where ResourceName is the case-sensitive resource name you are setting, and
Value is the value to which you are setting it.
ignored.

Table 4. Defined Resources for the DDEML/SMP Interface
IntegrityTime 300 Interval to do a full scan for SCADA
ScadaSource tjrSrc The SCADA source name
ScadaPort 5020 or 7000 Listening port of the SCADA Server (5020 for
NTLM/Kerberos authentication and 7000 for
certificate-based authentication)
StptFeedbckTime 4 Interval in seconds to feedback unit MW output to
the unit is setpoint when in local mode
Host1 localhost String specifying the host name for the SCADA
connection
Host2 String specifying the host name for the secondary
SCADA connection in a dual-state environment
connection
connection
LogErrors True Set to True to save the messages generated to a
file. Log files are generated in the application
directory path.
DebugVerbose False To enable verbose debug output
QueueTime 0.5 Time in seconds to retry DDEPoke
UseRequest True Set to True if DDERequest transaction mode is
used
RequestInterval 0 Interval in seconds to request the data. Should be
greater than zero if “UseRequest” is set to True.
UseAdvise True Set to True if DDEAdvise transaction mode is used
SrvConRetryTime 30 Interval in seconds to retry DDE server connection
ShowDebug True Show Debug Output dialog
ScadaSdbName The Scada database name including its full path.
Needed if there are multiple instances of the Scada
server running on the same machine.
Each type of DDE item has its own format. The first line defines the type of DDE item.
Leading spaces are removed and are optional.

Table 5. Item Definition for the DDEML/SMP Interface
DIGITAL Digital point
SMP-Name e-terracontrol device name
DdeTopic DDE Topic string
DdeItem DDE Item string
StatusMask Mask (decimal) to AND with DDE item value to get status
BadMask Mask (decimal) to AND with DDE item value to get bad quality
OldMask Mask (decimal) to AND with DDE item value to get old quality
Manual Mask This is an optional parameter to specify a manual entry mask.
Manual Quality Specifies the manual entry quality. This parameter is not optional if Manual
Mask is specified.
ANALOG Analog point, puts engineering value
DdeValueTopic DDE topic string for analog value
DdeValueItem DDE item string for analog value
DdeQualityTopic DDE topic string for analog quality
DdeQualityItem DDE item string for analog quality
BadMask Mask (decimal) to AND with DDE quality item value to get bad quality
OldMask Mask (decimal) to AND with DDE quality item value to get old quality
Mask is specified.
ANARAW Analog point, puts raw value
DdeValueTopic DDE topic string for analog value
DdeValueItem DDE item string for analog value
DdeQualityTopic DDE topic string for analog quality

DdeQualityItem DDE item string for analog quality
Mask is specified.
SETPNT Setpoint
SMP-Name e-terracontrol setpoint device name
DdeValueTopic DDE topic string for setpoint value
DdeValueItem DDE item string for setpoint value
DdeQualityTopic DDE topic string for setpoint quality
DdeQualityItem DDE item string for setpoint quality
Mask is specified.
STPTFB Setpoint with feedback
SMP-Name e-terracontrol setpoint device name
DdeValueTopic DDE topic string for setpoint value
DdeValueItem DDE item string for setpoint value
DdeQualityTopic DDE topic string for setpoint quality
DdeQualityItem DDE item string for setpoint quality
RemoteLocalPoint Digital “SMP-Name” point, which indicates generator’s remote/local status

Mask is specified.
ANAOUT Analog output
Station e-terracontrol station name
SMP-Name e-terracontrol analog output device name
DdeValueTopic DDE topic string for analog output value
DdeValueItem DDE item string for analog output value
DdeQualityTopic DDE topic string for analog output quality
DdeQualityItem DDE item string for analog output quality
Mask is specified.
ANARAWOUT Analog raw output
SMP-Name e-terracontrol analog raw output device name
DdeValueTopic DDE topic string for analog output value
DdeValueItem DDE item string for analog output value
DdeQualityTopic DDE topic string for analog output quality
DdeQualityItem DDE item string for analog output quality
Mask is specified.
DIGOUT Digital output
SMP-Name e-terracontrol digital output device name

DdeStatusTopic DDE topic string for digital output status/quality
DdeStatusItem DDE item string for digital output status/quality
StatusClosed Value indicating closed (1) position
StatusOpen Value indicating open (0) position
Mask is specified.
CONTROL Control output
SMP-Name e-terracontrol digital output device name
DdeStatusTopic DDE topic string for control output status/quality
DdeStatusItem DDE item string for control output status/quality
StatusMask Mask (decimal) to AND with DDE item value to get status
Mask is specified.
Note: If the point does not have a quality code, set the “mask” to 0 and the “quality” to

3.4.1 DDEML/SMP Interface Configuration File Example
# DDEML/SMP Interface Configuration File
UseAutomatic: True
IntegrityTime: 300
RetryTime: 0
ScadaSource: WdpfSrc
ScadaInterval: 2000
StptFeedbckTime: 60
ValueWidth: 1200
QualityWidth: 1200
CommentWidth: 2600
MainWidth: 7400
MainHeight: 6600
UseRequest: True
RequestInterval: 120
UseAdvise: True
SrvConRetryTime: 30
ScadaSdbName: d:\eterra\e_terracontrol\samples\emp60_rtus.sdb
DIGITAL
1BS16022C
G1 Online Status 1
wwwdde|DataGet
A1BS16022C_DS
1
1
768
768
32768
32768
STPTFB
3SMPMW
G3 MW Setpoint 18
wwwdde|DataPut
A3SMPMW_AV
wwwdde|DataPut
A3SMPMW_AS
768
768
32768
32768
3REMOTE
3JT16001S

3.5 DDE Simulation Program
A test DDE server program, “wwwdde”, is provided. This is a Visual Basic application
that simulates the functionality of an actual DDE server.
The wwwdde application provides some simulation capability for frequency and
generation response to setpoint changes. Each unit has its own simulation enable
check box, with the frequency simulation function having its own simulation enable
check box as well. The tie line MW simulation is simply the net generation divided by
two for each line. The frequency is 60Hz plus the difference between scheduled and
actual interchange multiplied by the frequency sensitivity, plus an optional random noise
component.
The test application simulates the data available from ddeml2smp. The columns marked
“AV” are the analog values for the tags, and the columns marked “AS/DS” are the
analog/digital statuses for the tags. Tag names are shown on the left. The simulator
models four generators, where each generator i has the tags:
• AiBS16022: Generator online status (1=Online)
• AiREMOTE: Generator remote/local indication (1=Remote)
• AiJT16001S: Generator MW output
• AiJT16013: Generator MVAR output
• BRLMWGi: Generator low control limit in MW
• BRHMWGi: Generator high control limit in MW
• AiST16003: Generator frequency measurement
The Test DDE Setpoint window (Figure 6) receives setpoints and performs a linear
ramping function for each unit if the Simulation check box on the test application window
is toggled ON. The Test DDE Setpoint window appears at the startup of the application.

Figure 5. Test DDE Application – wwwdde
Figure 6. Test DDE Setpoint Window

4. InterSite Data Application
The InterSite Data (ISD) application is used to send and/or receive data between
e-terracontrol and an e-terraplatform system, or between e-terracontrol systems.
You can define which points in the local SCADA database you send data to. You can
also define which points receive data from other Energy Management System (EMS)
sites.
InterSite Data supports InterSite controls for breaker and relay control execution.
The database of the ISD application contains NETIO path names, site names, CPU
names, and the port of the PROXYSRV application. The database saves these to an
.isd file, which is the equivalent of a SCADA .sdb file.
In the SCADA application, each measurement has an “external name”. For
e-terraplatform users, this must match the e-terrahabitat name for ISD to work. For
example, “CHENAUX.LN.34502.MW” for an external name maps to the e-terraplatform
SCADA analog record with the virtual key of SUBSTN=CHENAUX, DEVTYP=LN,
DEVICE=34502, ANALOG=MW.
The ISD protocol causes each side to negotiate the names wanted when the connection
is formed. If the names match, the data transfer takes place, and the requesting site
specifies the source site for the measurement.
4.1 InterSite Data Command-Line Arguments

An ISD shortcut is created during the installation of e-terracontrol. The application can
be launched from the Process Starter, a command line, a batch file, or a Windows
shortcut created with the appropriate command-line arguments included.
The name of the ISD configuration file (*.isd file) should be the first command-line
argument.
Optionally, if the e-terracontrol SCADA server is not running locally, there are
command-line arguments to specify the servers where it can be running
(/SCADAHOST1, /SCADAHOST2, /SCADAHOST3, and /SCADAHOST4).
You can specify up to four possible network addresses for the ISD application to try to
connect to. In most cases, the SCADA server runs on the same server as the ISD
application, so these parameters are not needed.
There is also an optional /SCADAPORT argument for specifying the port that the
SCADA server is listening on if it is not the default (5020 for NTLM/Kerberos
authentication and 7000 for certificate-based authentication).
The optional /ONLINE command-line argument sets the ISD in the online state upon
startup, allowing the ISD to attempt to connect to the remote site automatically.
The optional /DEBUGLOG command-line argument enables the detailed logging upon
startup.
Proprietary – See Copyright Page 23 InterSite Data Application

The following example demonstrates the syntax for these command-line arguments:
Isd.exe d:\eterra\e_terracontrol\db\olive_emp60.isd /ONLINE /DEBUGLOG
/SCADAHOST1 PC8821 /SCADAHOST2 PC8822 /SCADAHOST3 PC8823 /SCADAHOST4 PC8824
4.2 InterSite Data User Interface

Figure 7 shows the ISD interface window. The parameters in the gray boxes can be
edited only when ISD is offline.
Figure 7. InterSite Data User Interface Window
The following are included in the InterSite Data user interface window:
• Local Site: Enter the name of the local site. This must match the “remote site” name
on the remote node.
• Local Scanner: Enter the scanner path for the local site. This must match the
“remote site” path on the remote node.
• Local Control: Enter the control path for the local site. This must match the “remote
site” path on the remote node.

• Remote Site: Enter the name of the site for which points to send data to and receive
data from other sites are defined. For e-terraplatform users, this must match the
foreign site. Currently, e-terraplatform requires two-character uppercase names,
e.g., “TE”.
• Remote Scanner: Enter the scanner path for the remote site. This must match the
“local site” path on the remote node.
• Remote Control: Enter the control path for the remote site. This must match the
“local site” path on the remote node.
• Remote Port: Enter the PROXYSRV listening port. The default number is 5001.
• Refresh Rate: This is the rate, in milliseconds, that the SCADA server refreshes the
InterSite Data application with updated values. This can be set as low as 100 ms.
The default is 0, in which case the refresh rate defined on the SCADA server is
used. Configuring a fast refresh rate can reduce data latency, but it can also
adversely impact performance and the loading of the SCADA server.
• Keepalive Timeout Rate: This defines the timeout of the keepalive timer. If the
InterSite Data application has not received a message from the remote site in the
number of seconds defined in this field, the InterSite Data application automatically
disconnects and periodically attempts to reconnect.
• Remote Host: Enter the names of the node names where PROXYSRV is running.
• Receiving: Shows measurements requested from the foreign site.
• Sending: Shows measurements that the foreign site has requested and that ISD is
transferring.
• Status History: Defines the maximum delay when events are added in the history
queue before this queue becomes cyclical (one event added at the tail, oldest event
removed on top). This is done to limit the number of stored events in the case of a
very long time disconnection. The unit is minutes. The default value is 480 (eight
hours).
• Integrity Scan Rate: This defines the periodicity of the InterSite Data application to
send the integrity scan data. The term “integrity scan” means that all data is sent to
the remote site. The valid range for the integrity scan rate is from 20 to 360000
seconds. Zero (0) means that the integrity scan functionality is disabled. The default
value is 300 seconds.
• Use Extended Types: When this check box is checked, extended data messages
returned from the source site include a timestamp identifying when the value was
last modified.

4.3 InterSite Data Menu Bar
The non-standard options on the menu bar are as follows:
View Menu
• Diagnostics: Select to display the Diagnostics dialog box (Figure 8).
SCADA Menu
• Online: Select to put ISD online. When online, the ISD application attempts to
connect to both the SCADA server and the remote ISD partner (e.g.,
e-terraplatform).
• Offline: Select to put ISD offline. When offline, the ISD application disconnects all of
its external connections.
4.4 ISD Diagnostics Dialog Box
Figure 8. ISD Diagnostics Dialog Box
The following are included in the ISD Diagnostics dialog box:

• Log ISD Protocol Messages: When checked, all ISD protocol messages are
logged.
• Log Status: When checked, all measurement status updates are logged.
4.5 User and Area Permissions

When the ISD application is transmitting measurement values to a remote site (acting
as the source), the area permissions of the user it connects to the SCADA server apply.
When the ISD application is receiving measurement values from a remote site (acting
as the destination), the area permissions of the data source it connects to the SCADA
server apply.

If the ISD application is both transmitting and receiving measurement values from a
remote site (bi-directional), the area permissions of the data source it connects to the
SCADA server apply.

5. Modbus/SMP Interface Application
The mb2smp application accepts analog and status measurements from a Modbus
master device. The application then writes those measurements to the e-terracontrol
database, and to transfer setpoints and analog and status measurements from SCADA
to the Modbus device. It does all of this using a Modbus OCX control, and it is generic
to allow configuration to connect to many Modbus devices.
The application supports both serial slave and Ethernet slave connections.
5.1 Modbus/SMP Command-Line Argument

An mb2smp shortcut is not created during the installation of e-terracontrol, because
there is an optional command-line argument associated with this application. The
application can be launched from the Process Starter application, a command line, a
batch file, or a Windows shortcut created with the appropriate command-line argument
included.
The mb2smp application reads the default configuration file, “mb2smp_config.txt”, from
the application directory path. The file name can also be passed in as a command-line
~\mb2smp
C:\Eterra\e_terracontrol\samples\ConfigurationFiles\mb2smp_config.txt
5.2 Starting the Modbus/SMP Interface Using the Process

Starter
useful in situations where it is desired that the Modbus/SMP interface application remain
3. To create a new Process Starter group, proceed to step 4. To add the Modbus/SMP
interface application to an existing group, select File > Upload, and choose the
desired .psc file to display the Configuration tab for Processes.
Proprietary – See Copyright Page 28 Modbus/SMP Interface Application

information.
If you do not know the location of the mb2smp.exe file, click the Ellipsis button (...)
Name: Modbus/SMP Interface
Program: C:\eterra\e_terracontrol\bin32\mb2smp.exe
Params (Optional): D:\Modbus_Files\mb2smp_config.txt
Directory:
9. Click OK.
10. Save the file.
5.3 Modbus/SMP Interface User Interface
Figure 9. Modbus/SMP Interface User Interface Window

The following are included in the Modbus/SMP Interface user interface window:
Header
Device Information
• Modbus Index: Displays the index of the Programmable Logic Controller (PLC) as
ordered in the configuration file.
• Type: Displays the type of network connection.
• Port: Displays port address.
• Slave: Displays the PLC address.
• Status: Displays the status of the Modbus/SMP server. It does not display the status
of the connection.
Point Information
SCADA.
• Modbus Index: Displays the index of the PLC where the point originates.
• Modbus Address: Displays the register address of the point.
• Raw: Displays the raw value received from the device.
• Value: Displays the value interpreted by the interface program from the query
results.
5.4 Modbus/SMP Interface Menu Bar

The non-standard option on the menu bar is as follows:
Tools Menu
• Debug Window: Select to display the Debug Output window.

5.5 Modbus/SMP Interface Debug Output Window
Figure 10. Modbus/SMP Debug Output Window
The following are included in the Modbus/SMP Debug Output window:

to the number shown in megabytes in the adjacent text box. This is also the
maximum size of individual log files when the Log Errors in File check box is
selected.
“mb2smp_yyyymmdd_hhmmss.log”, where yyyymmdd is the date and hhmmss is
the time.
5.6 Modbus/SMP Interface Configuration File Format

Settings are passed to the Modbus/SMP interface application through a configuration
text file. Guidelines are as follows:
ResourceName: Value
ignored.

Table 6. Defined Resources for the Modbus/SMP Interface
ScadaSource n/a e-terracontrol source name
ScadaPort 5020 or 7000 The SCADA server listening port (5020 for
NTLM/Kerberos authentication and 7000 for
certificate-based authentication)
Host1 localhost String specifying the host name for a SCADA
connection
Host2 String specifying host name for a secondary
SCADA connection in a dual-state environment
Host3 String specifying the host name for a SCADA
connection
Host4 String specifying host name for a SCADA
connection
ModbusIndexWidth 1440 Modbus index field width
ModbusIPWidth 1440 Modbus IP field width
ModbusSlaveWidth 1440 Modbus slave field width
ModbusStatusWidth 1440 Modbus status field width
SMPPointNameWidth 1440 e-terracontrol point name field width
ItemModbusIndexWidth 1440 Item’s Modbus index field width
ItemModbusAddrWidth 1440 Item’s Modbus address field width
TypeWidth 1440 Type field width
ValueWidth 1440 Value field width
CommentWidth 1440 Comment field width
LogErrors True Set to True if error message should be output to a
file
Note: Each type of item has its own format. The first line defines the type of item.
Table 7. Item Definition for the Modbus/SMP Interface

MBSS Modbus control – need one per serial port
Baud Rate 0: 110 baud
1: 300 baud

2: 600 baud
3: 1200 baud
4: 2400 baud
5: 4800 baud
6: 9600 baud
7: 14400 baud
8: 19200 baud
9: 38400 baud
10: 56000 baud
11: 57600 baud
12: 115200 baud
13: 128000 baud
14: 256000 baud
Comm Port 1-n
Data Bits 0 = 7 bits, 1 = 8 bits
DTREnable 0 = disabled, 1 = enabled
Handshaking 0 = disabled, 1 = enabled
Parity 0 = no, 1 = odd, 2 = even
PLC Address 1-nnnn
Protocol 0 = ASCII mode is used, 1 = RTU mode is used
Stop Bits 0 = 1 bit, 1 = 2 bits
RTS Enable 0 = disabled, 1 = enabled
MBES Modbus control – need one per serial port
AdvancedDiag TRUE or FALSE. Set to TRUE to enable advanced diagnostics.
CheckAddr TRUE or FALSE. Set to TRUE to enable Check Addr.
DeviceType 0 = Modicon, 1 = Enron
Header 0 = Modicon, 1 = none
MaxIdleTime Set to maximum idle time
PLC Address 1-nnnn
Port TCP port number
Protocol 0 = ASCII mode, 1 = RTU mode
ResponseDelay 0-nnnn
WriteLocal TRUE or FALSE (usually set to TRUE)
DIGITAL Digital point (from Modbus master to e-terracontrol)

SMP-Name e-terracontrol measurement device name. The actual device name used
is this name appended with “-i”, where i is the bit number (1 through 16).
For example, a digital measurement name of “Unit1Sts” in the mb2smp
configuration file name results in 16 measurements written in the Scada
database starting with device name “Unit1Sts-1” and ending with device
name “Unit1Sts-16”. Note that the measurements having device names
“Unit1Sts-1” to “Unit1Sts-16” must be assigned to mb2smp data source.
Modbus address Address of data point in Modbus device
Modbus type Modbus translation types:
Short = 16-bit signed integer
UnsShort = 16-bit unsigned integer
Long = 32-bit signed integer
Float = 32-bit NT floating point number
ModFloat = 32-bit IEEE floating point number (as interpreted by
Modicon/SquareD)
ANALOG Analog engineering value (from Modbus master to e-terracontrol)
Modbus address Address of data point in Modbus device (for 32-bit values, use the second
address)
Modicon/SquareD)
ANARAW Analog raw value (from Modbus master to e-terracontrol)
address)
Modicon/SquareD)

ANAOUT Analog engineering value (from e-terracontrol to Modbus master)
SMP-Station e-terracontrol station name
address)
ModFloat = 32-bit IEEE floating point number
(as interpreted by Modicon/SquareD)
ANARAWOUT Analog raw value (from e-terracontrol to Modbus master)
address)
DIGOUT Packed digital register (from e-terracontrol to Modbus master)
SMP-Station e-terracontrol measurement device name
1:SMP-Name1 Bit number and e-terracontrol device name pair. The bit number must
2:SMP-Name2 have a colon after it. Bits not specified are set to zero.
...
...
...
16:SMP-Name16
Modbus address Address of data point in Modbus device

SETPNT Setpoint engineering value (from e-terracontrol to Modbus master)
address)
SETPNTRAW Setpoint raw value (from e-terracontrol to Modbus master)
address)
Modicon/SquareD)
5.6.1 Modbus/SMP Interface Configuration File Example

# SMP/Modbus Interface Configuration File
ScadaSource: mb2smp
MainWidth: 14000
MainHeight: 11000
ModbusIndexWidth: 1225
ModbusSlaveWidth: 1241
ModbusStatusWidth: 3345
SMPPointNameWidth: 2400
ItemModbusIndexWidth: 1241
ItemModbusAddrWidth: 1418
TypeWidth: 1100
ValueWidth: 1700

CommentWidth: 3833
LogErrors: TRUE
# Modbus controls
MBSS
6
1
1
0
0
0
1
1
0
0
MBES
FALSE
TRUE
0
0
0
1
502
1
0
TRUE
ANARAWOUT
Kincard
Kincard_T1_2_MW_Inv
40001
UnsShort
Kincard T1 Mw
DIGOUT
Kirkland
1:540C BKR
2:530C BKR
3:100F BKR
4:101F BKR
5:102F BKR
6:103F BKR
7:CAP1 BKR
8:CAP2 BKR
9:T1L BKR
10:T2L BKR
40001
Kirkland Breakers

# Digital Inputs. The actual measurement written will #have an “–i” appended
to the SMP name given here. Also #these measurements must be assigned to
mb2smp #datasource in the scada database
DIGITAL
MCC02_N1START
00013
Short
Start Command
DIGITAL
MCC02 N1-2 PERM-1
40090
Short
Start Command

6. OPC DA Server Application
The OPCSrv application is an OPC DA server designed to communicate with OPC
clients.
The OLE for Process Control (OPC) standard was developed by a group of process
control vendors with the assistance of Microsoft Corporation. The goal of this group was
to work out a standard for accessing real-time data under the Windows operating
systems, based on Microsoft’s OLE/DCOM technology.
The e-terracontrol OPC DA client application (see “OPC DA Client” in the e-terracontrol
Reference Manual: Interfaces to Field Devices) addresses the Data Access (DA)
specification that defines an interface between client and server programs to access
process data. DA servers provide one or several DA clients with transparent access to
different data sources (e.g., sensors) or data sinks (e.g., controllers). DA clients can
have access to several DA servers at the same time (for additional information about
the installation and configuration of this application, refer to the e-terracontrol/OPC DA
Server Software Installation and Maintenance Guide).
6.1 OPC DA Server Command-Line Arguments

The following is a description of the OPCSrv executable command-line arguments,
which can be used when starting OPCSrv.exe from the command line or from the
Process Starter.
There are two command-line arguments: one is the configuration file name, and the
other is the data source name.
The configuration file name is specified with the /config command-line switch. The data
source name is specified with the /datasource command-line switch.
A sample of the OPCSrv command-line parameters is:
OPCSrv /config <configuration file name.xml> /datasource <datasource name>
Note: The configuration file name also contains a Data Source field. If both the
configuration file and the data source are given as command-line arguments, the data
source specified in the /datasource command line is also the data source specified in
the configuration file, which is replaced with the data source given through the
/datasource command-line switch.
6.1.1 Configuration File Name

The configuration file name specifies an existing configuration file, which was created by
using the configuration dialog box of the OPC DA Server application.
Proprietary – See Copyright Page 39 OPC DA Server Application

When the OPC DA Server application starts, it finds the configuration file in the following
manner:
• If a command line is specified, it is used as the configuration file name.
• If the command line is not specified, the value in the registry entry named
“ConfigurationFileName” under the registry key
HKEY_CURRENT_USER\Software\ESCA\OPCServer is used as the configuration
file name.
• If the command line is not specified and the value of the registry entry named
“ConfigurationFileName” is empty or the registry entry is missing, the file named
“OPCServerConfig.xml” under the working directory is used as the configuration file.
If the OPC DA Server application fails to read the configuration file, it creates a new
configuration file in the following manner, with the default values listed below. At this
time, if a data source is specified with a /datasource command-line switch, that data
source name is used as the default value instead of the one listed below.
• If the path and file name of the given configuration file are valid, the configuration file
is generated in the given path with the given name.
• If the path of the given configuration file is valid, the configuration file named
“OPCServerConfig.xml” is created in that path.
• If the path of the given configuration file is invalid, the configuration file named
“OPCServerConfig.xml” is created in the working directory of the application.
Table 8. Default Values of the Configuration Parameters

Parameter Name Default Value
Log Folder Name <Working directory>
Max Log File Size [kB] 256
Log To Display, Log Inf
Log Events Log Inf, Log War, Log Err
Configuration File Name <Working directory>\OPCServerConfig.xml
Data Source OPCServer
Min Update Rate 0
Host1 Localhost
Host2
Host3
Host4
ScadaConnectionTimeout 30 Sec
Port 5020

6.1.2 Data Source Name
The Data Source name specifies an existing data source in the e-terracontrol database
(for information about how to add a data source to the SCADA server application, refer
to “Data Source Dialog Box” in the e-terracontrol Reference Manual: Applications).
6.2 Starting the OPC DA Server Using the Process Starter

useful in situations where it is desired that the OPC DA server remain continuously
active on certain PCs (for such a situation, see section 6.6 OPCServer Single Instance).
3. To create a new Process Starter group, proceed to step 4. To add the OPC DA
server application to an existing group, select File > Upload, and choose the desired
.psc file to display the Configuration tab for Processes.
information.
If you do not know the location of the opcsrv.exe file, click the Ellipsis button (...)
Name: OPC DA Server
Program: C:\eterra\e_terracontrol\bin32\ OPCSrv.exe
Params (Optional): /datasource OPCServer /config C:\eterra\e_terracontrol\bin32
\OPCServerConfig.xml
Directory:
9. Click OK.

10. Save the file.
6.3 OPC DA Server Installation

The OPC Data Access server is installed as part of the e-terracontrol installation
process.
The user should first register the OPC server, executing the following command line:
OPCSrv RegServer
The OPC DA server uses Microsoft DCOM. Therefore, prior to using this server from
the network, it is necessary to configure, launch, and set access permissions for DCOM.
6.3.1 DCOM Configuration

To configure DCOM:
1. Run dcomcnfg.exe 32-bit version.
2. On the list of Distributed COM Configuration Properties, find the “ALSTOMGRID DA”
entry and select it.

3. Click the Properties button.
The ALSTOMGRID DA Properties dialog box appears.
4. Verify that the local path (as shown on the dialog box) is
D:\eterra\e_terracontrol\bin32\OPCSrv.exe
5. Select the Location tab.

6. Verify that only the “Run application on this computer” check box is selected.
7. Select the Security tab.
8. Under “Launch and Activation Permissions”, select Customize.

Under “Access Permissions”, select Customize.
Under “Configuration Permissions”, select Customize.
9. Under Access Permissions, click the Edit button.
Note: Be aware that adding “Everyone” does not mean that you have really
granted access to everyone. The domain controller or local policy can prevent

access to the PC on which the OPC server resides. Ask about your network
administrator’s access policies (for users, groups, and computers you are
concerned with).
10. Add a list of users you want to allow to access the Alstom Grid OPC server.
11. Back on the Security tab, under Launch and Activation Permissions, click the Edit
button.
12. Add a list of users you want to allow to launch the OPC server.
In a case where the OPC server is not already started, the first OPC client that tries
to connect to the server launches the OPC DA server application — if it has
permission for that.
13. On the Security tab, under Configuration Permissions, click the Edit button.
14. Add a list of users you want to allow to change the DCOM configuration for the OPC
DA server (it is probably the administrator or the user account under which the OPC
server runs).

15. In the ALSTOMGRID DA Properties dialog box, select the Identity tab.
If you have started the OPC server, even though there are no OPC clients’
connections, you may prefer to select “The interactive user” button.
6.4 OPC DA Server User Interface

The OPC DA server user interface provides the user with a tool for managing the OPC
DA server. The user interface provides the user with the ability to view the current
status, control, and configuration of the OPC DA server.

6.4.1 OPC DA Server Main Window
The OPC DA server user interface is a single document application whose view area
shows the most recent server’s events. These events are also stored in the text log file.
Figure 11. OPC DA Server Main Window
The following are included in the OPC DA server main window:

• Event Timestamp: The timestamp has the following format:
MMM, DD, YYYY HH:MM:SS
• Event Type: There are five possible event types:
– Inf: Informational
– War: Warning
– Err: Error
– Tra (Trace): Trace is used to trace event procedures from e-terracontrol.
– Ref (Refresh): Refresh events are usually very frequent information events — for
example, the client requests a data refresh or the server status.
• Event Description

6.4.2 Configuration Dialog Box
The Configuration dialog box provides a way to edit the base server’s configuration.
Figure 12. OPC DA Server Configuration Dialog Box
The following are included in the OPC DA server configuration dialog box:
• Log Folder Name: This text box defines the path of the application event log file.
• Max Log File Size: This text box limits the size of the log file.
• Log To: Choose logging methodology. Log to the user interface, log to file, or both.
• Log Events: Logging severity level selection.
• Configuration File Name: Defines the path and file name of the OPC server’s
configuration file. It persists all of the configuration data on this file.
• Data Source: The name that the OPC server uses for data exchange with the
e-terracontrol server application.
• Min Update Rate: The update rate in milliseconds for updated data between the
OPC server application and the e-terracontrol server application (this is not currently
implemented).
• Host1: Address of the primary SCADA Server
• Host2: Address of the secondary SCADA Server
• Host3: Address of the additional SCADA Server

• Host4: Address of the additional SCADA Server
• Scada Connection Timeout (Sec): This parameter is used to set the wait time of
the OPC DA Server application for connecting to the SCADA server if the SCADA
server connection is not already available when an OPC client tries to add the
subscription items.
• Scada Port : The listening port of the SCADA Server
6.5 Data Source and Data Set Configuration

The subsequent sections detail the data source and data set configurations for the OPC
DA server application.
6.5.1 Data Source

A new data source with the name specified in section 6.4.2 Configuration Dialog Box
needs to be added to the e-terracontrol database (for details about configuring new
data sources, refer to “Data Source Dialog Box” in the e-terracontrol Reference Manual:
Applications).
6.5.2 Data Sets

There is no limit on the number of OPCServer data sets that can be modeled in the
system. However, it is not recommended that more than three actually be modeled.
As an example, the first data set can hold all points with ReadOnly (R) access
permissions, and the second data set can hold all points with WriteOnly (W) access
permissions (for details about configuring new data sets, refer to “Data Set Dialog Box”
in the e-terracontrol Reference Manual: Applications).
The current implementation of the OPC Server does not require any data set
parameters.
6.6 OPCServer Single Instance

OPC server (OPCSrv.exe) is started automatically when it is invoked by any local or
remote OPC client.
If more than one OPC client (from multiple user sessions or different machines)
attempts to connect to the same OPC server, multiple OPC server instances are started
on machines running Microsoft Windows 2008 or another Windows operating system
that supports multiple user sessions with Session - 0 isolation.
To get a single instance of OPC server, use the Process Starter to start OPC server in
Session - 0 with the following condition:

• The identity credentials of OPC server set with DCOMCNFG (using the “This user”
option) should be the same as the Default User credentials of the Process Starter.
6.7 Configuration Settings for Connecting OPCClient with a

Remote OPC DA Server
Configure Machine A to run OPCClient and Machine B to run OPC DA Server. The
configurations mentioned are based on Windows Server 2008 R2.
1. Disable the firewall on Machine A and Machine B.
2. Configure the Local Security Policy settings of Machine B as follows:
– In Local Security Policy settings, set the "Network Access: Sharing and security
model for local accounts" policy to use Classic mode.
– In Local Security Policy settings, set the "Network Access: Let everyone
permissions apply to anonymous users" policy to Enabled.
After changing the security settings, restart the computer for the changes to take
effect.
3. See section 6.3.1 DCOM Configuration for configuring the OPC DA Server DCOM
component on Machine B. On the “Identity” tab of the OPC DA Server DCOM
component, select “This User” and enter the user credentials of Machine B.
4. The DCOM configuration for the OpcEnum DCOM component on Machine B is as
follows (the purpose of OpcEnum is to provide an interface into the local machine's
Component Category Manager that can be accessed by remote OPC clients over
DCOM):
– On the list of Distributed COM Configuration Properties, find the “OpcEnum”
entry and view its properties.
– Select the “Security” tab.
– Under “Launch and Activation Permissions”, add the users (Machine A user, the
user account under which the OPCClient runs, and Machine B user, the user
account under which the OPC DA Server runs) who need permission to launch
the OPC DA Server.
– Under “Access Permissions”, add the users (Machine A user and Machine B
user) who need permission to access the OPC DA Server.
5. Open a SCADA Server database.
6. Start Process Starter on Machine B and connect to the Process Starter Service.
The Default User in Process Starter should be given as Machine B’s user credential.
7. Configure the OPC DA Server in Process Starter and start Process Starter in
session 0.

8. Start OPCClient on Machine A with the appropriate data source.
OPCClient on Machine A establishes a connection with OPCDA Server running in
session 0 on Machine B.
6.8 OPCServer and Multiple Scada Instance

Although e-terracontrol supports multiple Scada instances running on the same
machine, only one instance of the OPC server can run on the same machine. This is
because OPCServer and OPCClient use Microsoft DCOM technology, which depends
on the Windows registry.
Since OPC usually only needs to access part of the Scada points, it is recommended to
model all OPC points in one Scada database. Then configure OPCServer and
OPCClient to communicate with that one Scada instance.

7. PI/SMP Interface Application
The pi2smp application reads analog and status measurements from an OSI PI
database. The application then writes those measurements to the e-terracontrol
database, and transfers setpoints and analog and status measurements from SCADA to
the OSI PI database.
7.1 PI/SMP Command-Line Argument

A pi2smp shortcut is not created during the e-terracontrol installation because there is
an optional command-line argument associated with this application. The application
can be launched from the Process Starter application, a command line, a batch file, or a
Windows shortcut created with the appropriate command-line argument included.
The pi2smp application reads the default configuration file “pi2smp.txt” from the
application directory path. The file name can also be passed in as a command-line
~\pi2smp D:\PI_Files\pi2smp.txt
The pi2smp application can be started with the following optional parameters:
• /exceptionhandler=xxx
Where XXX is fulldump or minidump.
This parameter allows the Process Starter to generate the fulldump or minidump file
when the application crashes for any known or unknown reason.
• /pitrust
This parameter indicates that PI server is configured to use trust mode, so pi2smp
should also connect to PI server in trust mode. Without this parameter, pi2smp
connects using the default non-trust mode.
• ScadaPort
This is an optional argument for specifying the port that the SCADA server is
listening on if it is not the default (5020 for NTLM/Kerberos authentication and 7000
for certificate-based authentication).
For example: ScadaPort=5025
• Host1, Host2, Host3, Host4
These are the optional arguments to specify the host names on which the
e-terracontrol SCADA server is running.
For example: Host1=<Machine Name>
Proprietary – See Copyright Page 52 PI/SMP Interface Application

7.2 Starting the PI/SMP Interface Using the Process Starter
useful in situations where it is desired that the PI/SMP interface application remain
3. To create a new Process Starter group, proceed to step 4. To add the
PI/SMP interface application to an existing group, select File > Upload, and choose
the desired .psc file to display the Configuration tab for Processes.
information.
If you do not know the location of the pi2smp.exe file, click the Ellipsis button (...)
Name: PI/SMP Interface
Program: C:\alstom\e_terracontrol\bin32\pi2smp.exe
Params: D:\PI_Files\pi2smp.txt
Directory:
9. Click OK.
10. Save the file.

7.3 PI/SMP Interface User Interface
Figure 13. PI/SMP Interface User Interface Window
The following are included in the PI/SMP Interface user interface window:
Header
Measurement Information
SCADA.
• Value Tag: Name of the corresponding tag in PI for the value.
• Value: Displays the last value transferred.
• Quality: Displays the last quality transferred.
7.4 PI/SMP Interface Menu Bar

The non-standard option on the menu bar is as follows:
Tools Menu
• Debug Window: Select to display the Debug Output window.

7.5 PI/SMP Interface Debug Output Window
Figure 14. PI/SMP Debug Output Window
The following are included in the PI/SMP Debug Output window:

to the number shown in megabytes in the adjacent text box. This is also the
maximum size of individual log files when the Log Errors in File check box is
selected.
“pi2smp_yyyymmdd_hhmmss.log”, where yyyymmdd is the date and hhmmss is the
time.
7.6 PI/SMP Interface Configuration File Format

Settings are passed to the PI/SMP interface application through a configuration text file.
Guidelines are as follows:
ResourceName: Value
ignored.

Table 9. Defined Resources for the PI/SMP Interface
ScadaSource tjrSrc e-terracontrol source name
SMPPointNameWidth 1440 e-terracontrol point name field width
TagNameWidth 1440 Value and quality tag name column widths
TagValNameWidth 1440 Value tag name column width
TagQualityNameWidth 1440 Quality tag name column width
TypeWidth 1440 Type column width
ValueWidth 1440 Value column width
QualityWidth 1440 Quality column width
CommentWidth 1440 Comment column width
PiServerName PI server name
PiIntegrityTime 300 PI integrity scan interval in seconds
PiRetryTime 5000 Interval in milliseconds to retry PI connection
PiSnapshotLimit 1000 Number of points PI can read at a time
PiConnectProcName SMP Connect name used in PI connect request
PiUserName User name to connect to PI
PiPassword Password to connect to PI
StptFeedbckTime 4 Interval in seconds to feedback unit MW output to
the unit is setpoint when in local mode
LogErrors True Set to True if error messages should be output to a
file
AbortProcess False Set to True if the process should abort if an error
occurs. Set to True if you notice you are having
trouble connecting to PI
XlateDigStates False Set to True if you want to specify text states for
OPEN and CLOSE states on DIGITAL and
DIGOUT records.
Note: Each type of item has its own format. The first line defines the type of item.
If a point does not have a quality code, set the “mask” to 0 and the “quality” to

Table 10. Item Definition for the PI/SMP Interface
DIGITAL Digital point – PI to SMP
SMP-name e-terracontrol measurement device name
ValueTag PI tag name for value field
QualityTag PI tag name for quality field – can be left blank or set to NULL
StatusOpen Value indicating open state, compared against status.
Note that PI does not use 1s and 0s to represent specific states — it has
a huge state table. The actual values returned by PI are large numbers,
such as 524288 for Open and 524289 for Closed. Using this example,
the state codes are specified in the configuration file as follows when the
XslateDigStates parameter is set to false:
DIGITAL
3AGC-2039SW
3AGC-2039SW
NULL
ELS Unit 3 AGC Status
524288
524289
0
1
0
1
BadMask Mask (decimal) to AND with status field to get bad quality
OldMask Mask (decimal) to AND with status field to get old quality
ANALOG Analog point, puts engineering value – PI to SMP
ANARAW Analog point, puts raw value – PI to SMP

SETPNT Setpoint – SMP to PI
STPTFB Setpoint with feedback – SMP to PI
RemoteLocalPoint Digital “SMP-Name” point, which indicates generator’s Remote/Local
status
ANAOUT Analog outpoint point, as engineering value SMP to PI

ANARAWOUT Analog raw value SMP to PI
DIGOUT Digital output point SMP to PI
StatusClosed Value indicating close state
Note that PI does not use 1s and 0s to represent specific states — it has
a huge state table. The actual values returned by PI are large numbers,
such as 524288 for Open and 524289 for Closed. Using this example,
the state codes are specified in the configuration file as follows when the
XslateDigStates parameter is set to false:
DIGOUT
CHENAUX
3AGC-2039SW
3AGC-2039SW
NULL
ELS Unit 3 AGC Status
524288
524289
0
1
0
1
StatusOpen Value indicating open state

7.6.1 PI/SMP Interface Configuration File Example

# Test PI SMP Interface Configuration File
ScadaSource: PiSrc
ScadaInterval: 1000
PiServerName: EPHIST
PiConnectProcName: SMP
PiUserName: piadmin
PiPassword: dummy
PiIntegrityTime: 30
PiRetryTime: 60000
StptFeedbckTime: 120
TagValNameWidth: 3100
TagQualityNameWidth: 10
TypeWidth: 800
ValueWidth: 1200
QualityWidth: 700
CommentWidth: 3000
MainWidth: 13000
MainHeight: 12400
XlateDigStates: True
DIGITAL
BB01.DAS AGC
BB01.DAS AGC
NULL
BBR.PLC.BBR1.CNT2
Open
Closed
0
1
0
1
ANALOG
BB02.DAS AMBIENT AIR TEMP
BB02.DAS AMBIENT AIR TEMP
NULL
BBR.PLANT.BBR_STN_TEMP.DEG2
0
1
0
1

8. ICCP Application
The ICCP Reader application enables e-terracontrol to exchange data with a remote
partner using the ICCP (also known as “TASE.2”) protocol.
Blocks 1, 2, 3, and 5 are supported, allowing SCADA data and controls to be sent and
received by e-terracontrol. Client, server, and dual-direction client/server associations
are supported. Both OSI and TCP/IP communications are supported.
Modeling for the ICCP interface is performed in three parts:
• The SCADA database, where data, controls, and setpoints to be exchanged over
ICCP are defined
• An SMP/ICCP configuration file, where parameters that are ICCP-specific are
defined
• The OSI Stack database, where addressing information and OSI parameters are
defined
Graphical interface displays are available to monitor the operation of the SMP/ICCP
application. These include:
• A main display window showing the status of the association with a remote site and
the status of the data sets exchanged with that site
• Pop-up windows to view more-detailed information and to allow changes in remote
and data set parameters
• Data set contents
• Remote/data set parameters
• Logs
The available ICCP operations include:
• Removing topology components (Remote and Paths) and data sets from service and
returning them to service
• Changing operational parameters
• Viewing data item values/quality
• Viewing, activating, and deactivating logging
• Securing ICCP operations using the Secure MMS stack from SISCO
This application is not provided in the standard release of e-terracontrol. However, it is
both supported by and available from Alstom Grid (for details about application
modeling and real-time operations, refer to the ICCP application manuals).
Proprietary – See Copyright Page 61 ICCP Application

9. XX/SMP Interface Application
The xx2smp application is used to transfer data to and from the e-terracontrol database
via specific protocols.
xx2smp reports measurements from the SCADA database (to one or more remote
masters) and sends setpoints/controls to the SCADA database (from one or more
remote masters).
xx2smp uses the ProtocolPak ActiveX control to provide the actual low-level protocol
support itself.
The following protocols are currently supported:
• DNP 3
• IEC 870-5-101
• IEC 870-5-104
• Telegyr 8979
Further protocols can be added in the future.
The following communication layers are supported:
• Serial
• Network (TCP/UDP)
• Secure Network (using SSL)
All aspects pertaining to secure network communications are discussed in the
ProtocolPak Security Configuration User’s Guide.
The xx2smp application interfaces to e-terracontrol through two ScadaDevice controls
and an array of Subscriber controls.
9.1 Command-Line Arguments

Command-line arguments must be provided to the xx2smp application in order for it to
be started successfully.
xx2smp is usually launched from the Process Starter application.
The command-line arguments can be provided in a number of different formats. Some
command-line arguments consist of just a switch; others consist of a switch and an
associated value.
The following formats are acceptable, where “p” is the command-line argument switch,
and <Argument> is the command-line argument value:
-p
-p <Argument>
-p=<Argument>
Proprietary – See Copyright Page 62 XX/SMP Interface Application

/p
/p <Argument>
/p=<Argument>
Note: The switches themselves are case-sensitive — i.e., “-s” does not perform the
same function as “-S”.
Multiple command-line arguments must be separated with a space.

Importantly, the majority of command-line arguments are optional. The required/optional
status of each command-line argument is included with its description in the following
sections.
An example of a common set of command-line arguments is as follows:
-n xx2smp -z=D:\Temp\Traces\
For detailed information about each command-line argument, refer to the following
sections. Notably, some command-line arguments require a specific format in which
their argument must be supplied.
9.1.1 Command-Line Arguments Quick Reference
Table 11. xx2smp Command-Line Arguments Quick Reference

Switch Description Required
-a SCADA Connection Timeout No
-b Startup Delay No
-c Configuration Check No
-C Controls Response to Remote Master No
-d Configuration Data Source Mode – Data Set No
-e Engineering Unit Value Display Format No
-f Configuration File Name Deprecated
-g Reference Name for Point Identification No
-i Log Box Diagnostic Message Level No
-l Log File Diagnostic Message Level No
-L Do Not Add Measurements to Diagnostics Window List View No
-m Configuration Data Source Mode – Measurement Tree Deprecated
-n Data Source Name Yes
-o Measurement Write Timeout No
-p Change-of-State Notification – Passive No
-q Quality Ignore No
-r Raw Values Deprecated

Switch Description Required
-s Synthesized Values Deprecated
-S Log File Rollover Size No
-t Configuration Data Source Mode – Text File Deprecated
-u Change-of-State Notification Source – Unsolicited No
-v e-terracontrol Version No
-x Allow Remote Exit Command No
-z Log File Folder No
-host1, Host Arguments No
-host2,
-host3,
-host4
-port Listening port of the SCADA Server application No
-sdb Scada database name including its full path No
Note: Table 11 indicates that the “-n” command-line parameter is required. All other
parameters are optional or deprecated.
9.1.2 SCADA Connection Timeout

The “-a” command-line argument sets the connection timeout value between xx2smp
and SCADA. This timeout applies to both the automation and ScadaDevice interfaces.
-a <ScadaTimeout>
Where <ScadaTimeout> is the timeout value in seconds.
If not supplied, a default of 10 seconds is used.
The -a command-line argument is optional.
9.1.3 Startup Delay

The “-b” command-line argument defines a delay period after which xx2smp enables all
configured points. The delay period applies after startup of the application. Before this
delay period expires, all points are marked as uninitialized. xx2smp does not respond
with valid data to requests from the remote station during this period. The status can be
viewed in the xx2smp diagnostics window under the Status and Enabled columns.
The delay allows the xx2smp application to “settle” after startup, before becoming ready
to provide data in response to requests from remote station(s).
-b <Timeout>

Where <Timeout> is the timeout value in seconds.
If not supplied, a default of 5 seconds is used.
The -b command-line argument is optional.
9.1.4 Configuration Check

The “-c” command-line argument directs xx2smp to stop after successful configuration
and to not proceed to the operational state. This command-line argument is used for
debugging purposes, in order to check that the configuration is satisfactory without
entering the operational state thereafter.
-c
The -c command-line argument is optional.
9.1.5 Controls Response

This argument is used only for IEC101 and IEC104 protocols. If this parameter is
passed on the command line, xx2smp sends the activation termination command to the
remote master even if SCADA fails to execute the control.
-C
The -C command-line argument is optional.
9.1.6 Configuration Data Source Mode – Data Set

The “-d” command-line argument directs xx2smp to browse the databases data set tree
for its configuration. The recommended means to configure xx2smp is via data sets.
The “-d” command-line argument is the default configuration mode and, therefore, it
need not be supplied explicitly. If either the measurement tree (“-m”) or text file (“-t”)
configuration mode is selected, the default selection for “-d” is overridden.
-d
This argument can be contrasted with the “-m” and “-t” arguments, which direct xx2smp
to use a text file for its configuration. Both the “-m” and “-t” arguments are deprecated
and are provided for backward compatibility only.
For all users configuring xx2smp anew, the data set tree should be used for the
configuration. In such a case, it is optional to supply the –d command-line argument
(since it is the default).
For users upgrading existing systems using the deprecated text file configuration
mechanism, the –m or –t command-line arguments can be used instead.

9.1.7 Engineering Unit Value Display Format
The “-e” command-line argument specifies how the engineering unit values are
displayed in the diagnostics window.
-e <FormatString>
Example (the default value):
-e ####0.0000
Where the “0” characters are zero fillers and the “#” characters are space fillers.
The –e command-line argument is optional.
9.1.8 Configuration File Name (Deprecated)

The “-f” command-line argument specifies the name of the file containing the xx2smp
configuration (when configuration via file is selected).
The “-t” argument must be supplied for the “-f” argument to be relevant.
If a configuration file is used to configure xx2smp, the “-t” argument must be provided. If
the “-f” command-line argument is not supplied in addition, the application looks for a
text file named “xx2smp.txt” for its configuration. If the configuration file is alternately
named, the “-f” command-line argument should be used to provide the file name. The
configuration file is always presumed to be located in the working directory of the
application.
-t -f <FileName>
For example: -t –f xx2smpConfig.txt
The configuration file mechanism is provided for backward compatibility purposes only
and is now deprecated. The data set configuration mechanism (specified with the “-d”
command-line argument) is preferred. Both the “-f” and “-t” command-line arguments
are deprecated.
Note: The ability to pass device timestamps to the remote master is only available in
the data set configuration mode (“-d”). Otherwise, the e-terracontrol timestamp is
used.
The -f command-line argument is optional.
9.1.9 Reference Name for Points

The “-g” command-line argument allows the user to choose the identification names of
all the points. The points can be identified either by the Name column or by the Number
column in the Scada.exe points table.
-g
If the –g command-line argument is present, the Number column is used.

If the –g command-line argument is not present, the Name column is used.
If the Name column is chosen to identify the points, this column should contain only
numeric values. The specified numeric values identify the points in protocol exchanges.
The -g command-line argument is optional.
9.1.10 Log Box Diagnostic Message Level

The “-i” command-line argument directs xx2smp as to the types of diagnostic messages
to be displayed in the log box in the main application window.
-i <Level>
Where <Level> is one of the following:
NONE: Displays no diagnostic messages whatsoever
ERROR: Displays only error messages
WARNING: Displays error and warning messages
OTHER: Displays error, warning, and informational messages
If this argument is not provided, the default level is set to “WARNING”. In general,
production systems should use the default.
Be aware that setting this level to “OTHER” may result in the display of many
messages. Indeed, the volume of messages produced may lead to severe degradation
in the performance of the application and may affect communications with the remote
station. If required, the level of “OTHER” should only be selected while debugging. In
general, the level of “OTHER” should not be selected on production systems because of
the potential impact that it may have on communications.
If you require the diagnostic level of “OTHER”, a better solution is often to set the log file
diagnostic message level to “OTHER” (with the –l command-line parameter), since this
has a much lower performance impact. The xx2smp log file(s) can then be perused at
leisure.
The maximum size of the log box is limited to 100k. Once the log box reaches this size,
the oldest messages are removed in order to make space for any newly arriving
messages.
The -i command-line argument is optional.
9.1.11 Log File Diagnostic Message Level

The “-l” command-line argument directs xx2smp as to the types of diagnostic messages
to be logged to the log file on disk.
-l <Level>
Where <Level> is one of the following:
NONE: No log file is created

ERROR: Logs only error messages
WARNING: Logs error and warning messages
OTHER: Logs error, warning, and informational messages
If this argument is not provided, the default level is set to “WARNING”. In general,
production systems should use the default.
Setting this level to “OTHER” has a noticeable impact on application performance.
However, this impact is not nearly as severe as setting the log box diagnostic message
level to “OTHER” (with the –i command-line parameter).
Note: If the command-line parameter “-l NONE” is specified, no log file is created. This
can be useful on machines without disks or wherever the creation of an xx2smp log
file is of no interest.
The -l command-line argument is optional.
9.1.12 Adding Measurements to Diagnostics Window

If this parameter is passed on the command line, xx2smp does not add the
measurements modeled in the xx2smp data sets to the diagnostics window list view.
This parameter should be used when the database is very big and xx2smp is taking a
long time to initialize.
-L
The -L command-line argument is optional.
9.1.13 Configuration Data Source Mode – Measurement Tree

(Deprecated)
The “-m” command-line argument directs xx2smp to read a file that is similar to the one
used in text file configuration mode (with the “-t” and “-f” parameters). However, in this
case, it exposes all of the measurements, controls, and setpoints under the Stations
node. The object addressing is determined by the order that is presented in the text file.
-m
This argument can be contrasted with the “-d” and “-t” arguments. The “-d” argument is
the recommended mechanism to configure xx2smp.
The “-m” and “-t” arguments are deprecated and are provided for backward compatibility
only.
data set configuration mode (-d). Otherwise, the e-terracontrol timestamp is used.
The -m command-line argument is optional.

9.1.14 Data Source Name (REQUIRED)
The “-n” command-line argument specifies the name of the data source in the SCADA
database that xx2smp is to use when connecting to the database. This data source is
used to read measurement values, write status values, and execute controls. This data
source requires Read access to the xx2smp measurement data set tree and Write
access to the xx2smp status data set tree.
A data source with this name must be present in the “data sources” branch in the
SCADA database.
In data set configuration mode (with the “-d” command-line parameter provided), the
data set associated with this data source is used to configure xx2smp.
-n <DataSourceName>
The -n command-line argument is required.
9.1.15 Measurement Write Timeout

For measurements written to e-terracontrol, the “-o” command-line argument specifies
the number of seconds before the output values are set to the data quality of OLD if
they have not been refreshed during this period. Setting this argument to 0 disables the
timeout option. The default value is 0.
-o <NumberOfSeconds>
The -o command-line argument is optional.
9.1.16 Change-of-State Notification – Passive

The “-p” command-line argument instructs xx2smp as to whether change-of-state
notifications should be passed from the database to the remote station. By default,
change-of-state notifications are always passed to the remote station. If this command-
line argument is supplied, change-of-state notifications are not passed to the remote
station.
-p
The -p command-line argument is optional.
9.1.17 Quality Ignore

The “-q” command-line argument directs xx2smp to ignore e-terracontrol data quality
attributes. If this command-line argument is not supplied, xx2smp processes
e-terracontrol data quality as normal.
This option should be used for testing purposes only.
-q
The -q command-line argument is optional.

9.1.18 Raw Values (Deprecated)
The “-r” command-line argument directs xx2smp to consider all items in the indicated
category as being raw. If no category is specified, all items are considered raw.
This option is only available when running in Text (“-t”) or Measurement (“-m”) mode.
Note: Since the “-t” and “-m” command-line arguments are deprecated, the “-r”
command-line argument is also deprecated.
-r <Category>
Where <Category> is one of the following:
m: Measurements
s: Controls and Setpoints
The -r command-line argument is optional.
9.1.19 Synthesized Values (Deprecated)

The “-s” command-line argument directs xx2smp to consider all items in the indicated
category as synthesized. In such a case, the engineering units value is read from the
database, and a raw value is derived from the scaling attributes. If no category is
specified, all items are considered synthesized. This option is only available when
running in Text (“-t”) or Measurement (“-m”) mode.
Note: Since the “-t” and “-m” command-line arguments are deprecated, the “-s”
command-line argument is also deprecated.
-s <Category>
Where <Category> is one of the following:
m: Measurements
s: Controls and Setpoints
The -s command-line argument is optional.
9.1.20 Log File Rollover Size

The “-S” command-line argument specifies the maximum size that an individual xx2smp
log file can reach before a new file is created — i.e., before a rollover occurs. When this
size is reached, the current log file is closed and a new log file is opened.
Note: The –S argument requires the use of an uppercase “S”.
-S <Size>
Where <Size> is in bytes.

The default value is 524288 (512k). A value less than 102400 is not permissible; if a
value less than 102400 is provided, the size is clamped to 102400.
The log file rollover mechanism is provided so that it is possible to periodically clean up
old log files without interrupting the application. This is possible, since only the current
log file is in use by the application at any one time. Therefore, old log files can be
deleted, moved, or archived.
The -S command-line argument is optional.
9.1.21 Configuration Data Source Mode – Text File (Deprecated)

The “-t” command-line argument instructs xx2smp to use a text file for its configuration
rather than browsing the database for its configuration (which is enabled by passing the
“-d” command-line argument). The “-f” argument can be used in conjunction with the “-t”
argument.
-t
The text file mechanism of configuring xx2smp is provided for backward compatibility
purposes only and is now deprecated. The data set configuration mechanism (specified
with the “-d” command-line argument) is preferred. Both the “-t” and “-f” command-line
arguments are deprecated.
the data set configuration mode (“-d”). Otherwise, the e-terracontrol timestamp is
used.
The -t command-line argument is optional.
9.1.22 Change-of-State Notification Source – Unsolicited

The “-u” command-line argument instructs xx2smp as to how it should receive change-
of-state notifications from e-terracontrol.
-u <Source>
Where <Source> is one of the following:
DATASETS: Source is the ScadaDevice control
MEAS: Source is the Subscriber control
If this argument is not provided, the default is taken as “DATASETS”. In the vast
majority of cases, the default setting of “DATASETS” is acceptable.
The -u command-line argument is optional.

9.1.23 e-terracontrol Version
The “-v” command-line argument informs xx2smp of the version of e-terracontrol that is
in use.
-v <Version>
For example: –v=3.2.1.4
If xx2smp is being used with the matching version of e-terracontrol (with which it was
shipped), there is no need to supply the “-v” command-line parameter.
Note: Running the current release of xx2smp with an old release of the SCADA server
is not supported. Unless circumstances forbid it, in most cases it is wise to run the
matching version of the SCADA server.
In the vast majority of cases, the -v command-line argument is optional.
9.1.24 Allow Remote Exit Command

Some protocols provide for commands that can be used to request the restart of a
Remote Terminal Unit (RTU) — e.g., the DNP 3.0 “Cold Restart” command. xx2smp
provides support for this functionality through the “-x” command-line parameter.
The “-x” command-line argument informs xx2smp that it should permit remote station(s)
to terminate the application. Under such circumstances, Process Starter typically
restarts the application thereafter.
The “-x” command-line argument takes an optional argument that specifies the number
of seconds to wait between accepting the request and actually shutting down the
application. If the “-x” command-line argument is not provided, any restart requests
received from a remote station are ignored and the application is not restarted.
-x [<delay>]
Where <delay> is an optional delay in seconds.
The -x command-line argument is optional.
9.1.25 Log File Folder

The “-z” command-line argument specifies the folder in which to write the xx2smp log
files. The path name itself must be provided as an absolute path name — e.g.,
D:\MyDir\MySubDir.
A trailing “\” at the end of the path name is optional. Relative path names are not
supported. If the path includes spaces, it must be enclosed in double quotation
marks — i.e., “D:\My Dir\My Sub Dir”.
-z=<Path>

Where <Path> is the absolute path name for the directory in which log files are to be
written. Importantly, an equals sign must be used when specifying this command-line
argument — i.e., -z=“D:\My Dir\My Sub Dir” or -z=D:\MyDir\MySubDir, etc.
It is not permissible to use a space between the “-z” and <Path> elements.
If this parameter is not specified, trace files are written to the current working directory
of the xx2smp application.
The -z command-line argument is optional.
9.1.26 Host(s) Arguments

By default, xx2smp connects to the SCADA application running on the local computer.
However, in the case where the xx2smp application does not reside on the same
machine as the SCADA server, the address of the SCADA server must be passed in the
“host1” argument. In a dual-state environment, the “host2” argument is used to pass the
address of the secondary SCADA server. The two SCADA servers must store the same
data source to which xx2smp is dedicated. In cases where the host machines have
more than one NIC card, the “host3” and “host4” arguments can be used to specify the
additional IP addresses.
-host1=<HostName>, -host2=<HostName2>, -host3=<HostName3>, -host4=<HostName4>
The –host1, -host2, -host3, and –host4 command-line arguments are optional.
9.1.27 SCADA Port

This is an optional argument for specifying the port that the SCADA server is listening
on if it is not the default (5020 for NTLM/Kerberos authentication and 7000 for
certificate-based authentication).
For example: -port=5025
9.1.28 SCADA Database Name

This argument specifies the database file that the Scada server uses. It is required if
there are multiple instances of the Scada server running on the same machine. Without
this parameter, xx2smp will not be able to get database information from the correct
Scada instance. If there is only one Scada server instance running, this parameter is
optional.
For example: -sdb=d:\eterra\e_terracontrol\samples\emp60_rtus.sdb
9.2 User Interface

The xx2smp application consists of two principal windows. The first of these is the main
window, which appears upon startup of the application. The second is a diagnostics
window that is displayed upon request.
9.2.1 Main Window
The xx2smp main window displays messages pertaining to the operation of both
xx2smp and all ProtocolPak controls that have been loaded by xx2smp. The severity
level for messages logged to this window is set with the “-i” command-line parameter.
If any ProtocolPak control loaded by xx2smp is currently reporting a connected status of
disconnected, the indicator “DISCONNECTED” is shown in the title bar of the window.
Figure 15. xx2smp Main Window
9.2.1.1 ProtocolPak Status Messages

There are a number of conditions under which ProtocolPak reports status information to
xx2smp. This information is reported by way of events that indicate the type of the
message and may also include parameters associated with the message. These
messages are displayed in the main log window of the xx2smp application and are also
traced to the xx2smp log file.
The messages shown in Table 12 are used to indicate the status of the ProtocolPak
control to xx2smp and are sent under the conditions described.

Table 12. ProtocolPak Status Log Messages
Message Description
FATAL_ERROR Signaled when ProtocolPak encounters a
fatal error from which recovery is not possible
(such as a fatal initialization error or a fatal
run-time error).
COLD_RESTART Signaled when the controlling station sends a
cold restart request. xx2smp stops (and is
restarted by Process Starter) if the command-
line parameter “-x” has been provided. If this
command-line parameter is not provided, no
action is taken.
WARM_RESTART Signaled when the controlling station sends a
warm restart request.
PROTOCOLPAK_COMMUNICATIONS_INITIALIZING Signaled when initialization of the
ProtocolPak communications layer is
beginning.
PROTOCOLPAK_COMMUNICATIONS_INITIALIZED Signaled when initialization of the
_SUCCESSFULLY ProtocolPak communications layer has been
completed successfully. Note that this only
indicates that the local port (serial or network)
has been opened and ProtocolPak has
completed its communications layer
initialization successfully. It does not indicate
that communications with the remote station
have been established.
Note: When ProtocolPak is operating in secure communications mode, a number of

other messages can be displayed in the xx2smp log window (for detailed descriptions
of these messages, refer to the ProtocolPak Security Configuration User’s Guide).
9.2.1.2 Menu Bar

The non-standard options on the menu bar are as follows.
9.2.1.2.1 Log Menu

• Clear: Clears the message log pane in the main window.
9.2.1.2.2 Tools Menu

• Diagnostics: Displays the diagnostics debug window.

9.2.1.2.3 Security Menu
The options on the Security menu are pertinent only when secure communications are
in operation (for further information, refer to the ProtocolPak Security Configuration
User’s Guide).
• Change Token Pass Phrase: Displays the Token Passphrase Change dialog box
(only used for secure communications).
• Access Control List: Displays the Access Control List Entry dialog box (only used
for secure communications).
9.2.1.2.4 Debug Menu

The options in the Debug menu can be used to change the debug levels used by
ProtocolPak and/or xx2smp at run time. Any changes made here only apply until the
application is stopped. Upon restarting, either the supplied parameters or the defaults
are used.
Upon startup, a “tick” is placed next to the options that are currently selected. These
options might have been selected by supplying the appropriate parameter, or they can
be the defaults if no explicit selection was specified.
In most cases, operational production systems should be configured to display/log only
error and/or warning level traces (not informational level traces). In such a case, the
run-time modification of the trace level can be useful if problems are occurring. In this
case, you can temporarily increase the debug level for a short time, and then return it to
the original setting without stopping the application. There are many other situations in
which the run-time modification of the debug levels can be useful.
The options in the Debug menu are as follows:
• xx2smp: Allows the run-time debugging levels used by xx2smp to be changed “on
the fly”.
– Screen: Allows the log box diagnostic message level to be changed on the fly.
This setting is equivalent to the static start time setting, which can be specified
with the xx2smp command-line parameter –i (for the implications regarding this
setting, see section 9.1.10 Log Box Diagnostic Message Level for instructions on
using the command-line parameter –i).
Options are:
∗ NONE
∗ ERROR
∗ WARNING
∗ OTHER
– File: Allows the log file diagnostic message level to be changed on the fly. This
setting is equivalent to the static start time setting, which can be specified with
the xx2smp command-line parameter –l (for the implications regarding this

setting, see section 9.1.10 Log Box Diagnostic Message Level for instructions on
using the command-line parameter –l).
Options are:
∗ NONE
∗ ERROR
∗ WARNING
∗ OTHER
• ProtocolPak: Allows the run-time debug level used by ProtocolPak to be changed
on the fly. This setting is equivalent to the static ProtocolPak data set parameter
IPROP_DEBUG_LEVEL, which can be supplied in the CfeDS data set. If multiple
ProtocolPak controls are loaded by xx2smp, then changing this setting changes the
debug level for all of those controls (for additional information about the settings of
this parameter, see section 9.7.3 xx2smp Master Data Set).
Options are:
– 0 = None
– 1 = Fatal
– 2 = Fatal and Error
– 3 = Fatal, Error, and Warning
– 4 = Fatal, Error, Warning, and Informational
9.2.1.2.5 Help Menu

• Help Topics (xx2smp): Displays context-sensitive online help for the xx2smp
application.
• Help Topics (Security): Displays help for the security-related aspects of the
xx2smp application.
• About xx2smp: Displays the version of xx2smp that is in use.
• About ProtocolPak: Displays the version of the ProtocolPak ActiveX control that is
in use.

9.2.2 Diagnostics Window
Figure 16. xx2smp Diagnostics Window
The xx2smp diagnostics window displays useful information pertaining to both the
configuration of the application and the current state of the application.
The current local time is shown in the title bar of the window and is updated every
second. The “SCADA Update Time” indicates the last time data was communicated
between xx2smp and the SCADA server application.
The Refresh List Continuously check box is used to enable/disable refreshing of the
measurement list view. By default, the measurement list view refresh is disabled. This
check box has been added to speed up the communication between xx2smp and the
master.
The pane at the top of the window shows information pertaining to all of the remote
station interfaces that are currently configured. Each of these interfaces corresponds to
a single instance of ProtocolPak that has been loaded by xx2smp (i.e., each line
corresponds to a single CfeDS data set in the database).
For each of the remote station interfaces, the following information is displayed:
• Index: Displays the index allocated to this remote station interface
(0 – xx).
• Node: Displays the node number allocated to this remote station interface (0 – xx).
• Protocol: Displays the protocol that is in use on this interface (DNP, IEC, etc.).

• Type: Displays the type of communications that are in operation on this interface
(Serial, Network, or SecureNetwork).
• Port: Displays the port number. For serial communications, this is the COM port
number. For network (or secure network) communications, this is the network port
number.
• LocAddr: Displays the address of the local station.
• RemAddr: Displays the address of the remote (master) station.
• Status: Displays the link state.
• Errors: Displays the current error count for this control as reported by ProtocolPak.
This count represents the number of errors of level DEBUG_ERROR or
DEBUG_FATAL that have been reported by ProtocolPak since the application was
started. If this value is non-zero, it is indicative of potential problems on the link with
the remote station. In such a case, search the ProtocolPak trace file(s) for the string
“error” to find said errors. Under normal circumstances, this value should always
be 0. Note that this count only represents errors from the ProtocolPak control; it
does not represent errors from xx2smp itself.
• BytesTx: Displays the number of bytes that have been transmitted by the
ProtocolPak control since the application was started.
• BytesRx: Displays the number of bytes that have been received by the ProtocolPak
control since the application was started.
• Read: Displays the time of the last remote station read request.
• Write: Displays the time of the last remote station write request.
• Update: Displays the time of the last change-of-state update from SCADA to
xx2smp.
If the connection status reported by ProtocolPak is disconnected, the line representing a
remote station interface is colored red. If the connection status is reported as
connected, the line is colored black.
The lower pane on the diagnostics window displays all of the data items that have been
configured for the superset of remote station interfaces that have been configured.
The following information is displayed for each item:
SCADA.
• Master Index: Displays the master index for which this item is configured (0 – xx).
This corresponds to the index displayed in the upper pane of the diagnostics
window.
• Node Index: Displays the node index for which this item is configured (0 – xx). This
corresponds to the index displayed in the upper pane of the diagnostics window.

• TIB (Type, Index, Bit): Displays protocol-specific item information in the following
format:
TT(IIII);BB
Where:
– TT is the protocol-specific object type — i.e., 5 for IEC step position objects. This
corresponds to the setting of the “LINKDATATYPE” for this item in the
“ScanGroupDS” data set.
– IIII is the index of this item in the address space for the object.
– BB is the bit index for this item. This is only displayed for bit protocols. No bit
protocols are presently supported.
• SMP Type: Displays the e-terracontrol type of this item. This corresponds to the
setting of the “SMPDATATYPE” for this item in the “CardDS” data set and can be
one of the following:
– Status
– Analog
– Anaraw
– Anaraw2
– Counter
– CounterRaw
– CounterRaw2
– Control
– Setpoint
– SetpointRaw
– SetpointRaw2
– SetpointRaw3
– Limit
– LimitRaw
– LimitRaw2
• Enabled: Indicates whether the point is enabled for transmission or reception.
• Raw: Displays the raw value as retrieved from the SCADA database.
• Value: Displays the engineering units value.
• Quality: Displays the e-terracontrol data quality of this item. The following quality
flags can be shown:
– K = Unacknowledged
– A = Abnormal
– O = Old
– B = Bad
– N = Not In Service
– M = Manual

– U = Uninitialized
– I = Inhibited
– T = Tagged
– 1 = Limit1 Exceeded
– P = Test Bit Set
• Time: Displays the time of the last read/write or update for this item.
• Comment: Displays the comment associated with this item.
9.2.3 Security Configuration Windows

The “Change Token Pass Phrase” and “Access Control List” windows are used
specifically for systems using secure communications. The purpose of these windows is
explained in the ProtocolPak Security Configuration User’s Guide.
9.2.4 Window Position and Sizing

Upon startup, the xx2smp application displays both its main window and its diagnostics
window at default positions and with default sizes.
At run time, the user can alter the sizing and position of the windows. Upon shutdown,
xx2smp stores the window position and size for both the main and diagnostics windows
in two separate files on disk. These files are always stored in the working directory of
the xx2smp application and are named:
• xx2smp_ ZZZZZ_frmMain.ini (for the main window)
• xx2smp_ ZZZZZ_frmDebug.ini (for the diagnostics window)
where ZZZZZ is the data source name that xx2smp uses to connect to the
e-terracontrol database (this is of variable length). This is the same as the string
supplied with the “-n” command-line argument.
Upon startup, the information stored in these files is used to restore both the main
window and the diagnostics window to the same position and size as they had at the
last application shutdown.
Should these files be removed, the application displays the windows at their default
sizes.
9.3 xx2smp Log Files

The “-l” command-line argument specifies the types of diagnostic messages that are to
be logged to the xx2smp log files on disk. Under normal circumstances, the default
setting (WARNING) can be accepted. In this case, all error- and warning-level
messages are logged to a file.

If informational messages are desired in addition to error and warning messages, then
the level can be set to “OTHER”. Care should be exercised when selecting this level,
since it may result in the creation of large log files on disk.
The creation of xx2smp log files can be entirely inhibited by passing the parameter
“NONE” with the “-l” command-line argument.
The naming convention for xx2smp log files is as follows:
xx2smp_XXXXX_YYYYYYYY_ZZZZZ_YYYYMMDD_HHMMSS.log
Where:
• XXXXX is the name of the computer on which the application is running (this is of
variable length). This provides the means to match configuration files to particular
machines (so you know where a configuration file came from).
• YYYYYYYY is a unique “session” identifier that allows multiple xx2smp log files
(from a specific run of the application) to be associated with each other. Together, all
log files with a common session identifier represent an entire session of the
application.
• ZZZZZ is the data source name that xx2smp uses to connect to the e-terracontrol
database (this is of variable length). This is the same as the string supplied with the
“-n” command-line argument.
• YYYYMMDD_HHMMSS is the date and time the file was created. Note that this is
not the same as the date and time the last entry was made to the file.
The naming convention has been designed so that files from a particular “session” of
the application are grouped together when viewed in (for instance) Microsoft Windows
Explorer. The files are always shown in chronological order and grouped according to
application “sessions”.
Log files are created in the current working directory of the xx2smp application (unless
the “-z” command-line argument is provided with an appropriate path name).
9.3.1 xx2smp Log File Rollover

Rather than tracing to a single log file for the life of the application, xx2smp implements
the means to “roll over” log files.
This idea was implemented because it is not beneficial to log to a single file for the life
of the application, since a very large log file can be created. Such large files are difficult
to deal with. In addition, it is not possible to perform file cleanup tasks at run time, since
such a file cannot be deleted while the application is still running.
To that end, when each log file reaches a certain pre-determined maximum size, the
current log file is closed and a new log file is created. The new log file is created with
exactly the same name, except that the “YYYYMMDD_HHMMSS” is updated to reflect
the time the new file was created.

Upon the creation of this new file, the handle to the old file is released by the
application. This means that the old file can then be moved or deleted as desired by the
operator. In this manner, it is possible to delete or archive old log files at run time
without stopping the application.
The default maximum size that a log file may reach before it is closed (and a new file is
created) is 512k. This size can be modified via the “-S” command-line argument.
9.4 ProtocolPak Log Files

The ProtocolPak ActiveX control creates log files that are distinct from the xx2smp log
files. The ProtocolPak log files contain information specific to the communications and
protocol that are in use. In most cases, this information is of more interest than that
contained in the xx2smp log files.
The IPROP_DEBUG_LEVEL parameter (in the CfeDS data set) is used to set the level
of tracing information that is to be written to the ProtocolPak log files. The creation of
ProtocolPak log files can be entirely inhibited by setting the IPROP_DEBUG_LEVEL
parameter to 0.
The IPROP_DEBUG_FOLDER parameter (in the CfeDS data set) can be used to
specify the location in which the ProtocolPak log files are to be written. If not supplied,
the log files are written to the current working directory of the xx2smp application. Note
that this is distinct from the “-z” command-line parameter, which can be supplied in
order to set the location for the xx2smp log files (i.e., the locale of the ProtocolPak and
xx2smp log files can be set independently).
ProtocolPak creates a log file for each instance of the control that is loaded by the
xx2smp application. If xx2smp is maintaining multiple remote station links, it loads
multiple instances of the ProtocolPak control. An instance of the ProtocolPak control is
instantiated for each CfeDS data set in the e-terracontrol database.
The naming convention for ProtocolPak log files is very similar to that for xx2smp log
files and is as follows:
ProtocolPak_XXXXX_YYYYYYYY_ZZZ_YYYYMMDD_HHMMSS.log
Where:
• XXXXX is the name of the computer on which the application is executing (this is of
variable length). This provides the means to match configuration files to particular
machines (so you know where a configuration file came from).
• YYYYYYYY is a unique “session” identifier that allows multiple files from a particular
“session” of the application to be associated with each other (so that together they
represent an entire session of the application).
• ZZZ is a three-digit index used to identify the particular control that created this file.
This is required so that each ProtocolPak control traces to a separate file. “ZZZ” is a
number from 001 to 999 (incremented by 1 for each control that is loaded).

• YYYYMMDD_HHMMSS is the date and time the log file was created. Note that this
is not the same as the date and time the last entry was made to the file.
The naming convention has been designed so that files from a particular “session” of
the application are grouped together when viewed in (for instance) Windows Explorer.
9.4.1 ProtocolPak Log File Rollover

Rather than simply tracing to a single log file for the life of the application, ProtocolPak
implements the means to “roll over” log files.
This was implemented because it is not desirable to log to a single file for the life of the
application. If the tracing level (IPROP_DEBUG_LEVEL) is set to 4 (informational), this
can produce a very large log file in a short space of time. Such a large file is difficult to
deal with. In addition, it is not possible to perform file cleanup tasks at run time, since
such a file cannot be deleted while the application is still running.
To that end, when each log file reaches a certain pre-determined maximum size, the
current log file is closed and a new log file is created. The new log file is created with
exactly the same name except that the “YYYYMMDD_HHMMSS” is updated to reflect
the time the new file was created.
Upon the creation of this new file, the links to the old file are released by the application.
This means that old files can then be archived or deleted as desired by the operator. In
this manner, it is possible to clean up old log files at run time without stopping the
application.
The parameter IPROP_AUDIT_LOG_MAX_FILE_SIZE can be used to set the size
when the log file rolls over. This parameter represents the maximum size that each log
file can attain before it is closed and a new log file is created. The default rollover size is
512k.
9.4.2 Searching for Errors in ProtocolPak Log Files

Most errors that can be logged to the ProtocolPak log files can be found by simply
searching for the string “error” in the files. Do not perform a case-sensitive search, since
the string can appear in the file as either “error” or “Error”.
A log is made whenever an error occurs. Such logs generally contain the string “error” in
them. Therefore, searching for this string is an easy way to skip straight to sections of
the file that indicate that problems have occurred.
The log file rollover functionality means that you may need to search multiple files on
disk in order to find a particular error that has occurred.

9.5 ProtocolPak Connection Status Indicator
ProtocolPak maintains a number of status indicators that are communicated to xx2smp
every second. These indicators are described in section 9.7.12 xx2smp Status Data
Set.
One of these indicators is a “Connection Status” indicator. This indicator specifies
whether functional application layer communications with the remote station are in
progress.
At first glance, you might imagine that only simple logic is needed to determine whether
functional application layer communications with the remote station are active.
However, on closer inspection, it becomes apparent that some rather complex logic is
required in order to reliably determine whether a good application layer connection with
the remote station is indeed operational.
The logic thus implemented uses a number of parameters to customize its operation.
These parameters are described in section 9.7.3 xx2smp Master Data Set and are
named as follows:
• IPROP_CONN_STATUS_CALC
• IPROP_CONN_STATUS_UPDATE_PERIOD
• IPROP_CONN_STATUS_INIT_WAIT_PERIOD
If the remote station is deemed as disconnected, the connection status indicator is 0. If
the remote station is deemed as connected, the connection status indicator is 1.
The logic used to set the connection status is different for both serial and network
communications. This is due to the nature of the communications medium — i.e.,
network communications (via sockets) has a concept of connectivity whereas serial
communications does not.
There are two fundamental conditions under which the connection status is updated.
The first is a forced update. This occurs under different situations for both serial and
network communications. A forced update occurs
IPROP_CONN_STATUS_INIT_WAIT_PERIOD milliseconds after the first signs of a
connection establishment.
The second condition is a periodic update. Periodic updates occur occasionally after a
forced update, at the interval specified by the parameter
IPROP_CONN_STATUS_UPDATE_PERIOD. In the absence of a forced update,
periodic updates still occur at the period specified by
IPROP_CONN_STATUS_UPDATE_PERIOD.
At each update (either forced or periodic), the current application status is compared
with the status at the previous update. The periods these updates are stored at are
referred to as “snapshots”. A snapshot is taken when the application first starts (all
indicators are set to 0) and thereafter at every forced and periodic update.

The following indicators are used in determining the connection status:
• Error Count
• Bytes Rx
• Bytes Tx
• Event Tick
• Read Tick
• Write Tick
• Socket connectivity status (for network communications only)
The event, read, and write “tick” indicators are simply Boolean indicators that represent
whether a successful event read, static read, or static write has occurred since the last
snapshot. These values are reset at the end of each snapshot.
At each snapshot (due either to a forced or a periodic update), the value of each
indicator is compared with its value at the last snapshot, in order to determine the
connection status. The logic used to set the connection status can be customized via
the IPROP_CONN_STATUS_CALC parameter. This parameter can be used to remove
one or more indicators from the logic used to set the connection status.
Importantly, the logic used to set the connection status indicator does not provide a
100% guarantee that the application layer connection is indeed functional. Certain
obtuse problems can occur on the link that may go unnoticed by the connection status
logic. However, in general, the connection status logic provides an accurate indication
of the connection status with the remote station.
The current connection status is reported from ProtocolPak to xx2smp every second
(along with the error count and bytes Tx/Rx indicators). Note that all of these indicators
are reported to xx2smp every second, whether the connection status is connected or
disconnected.
The following sections describe the logic that is used to set the connection status flag
for both serial and network communications.
9.5.1 Serial Communications

Upon startup of the application, the connection status is set to 0 (disconnected).
A forced update is performed IPROP_CONN_STATUS_INIT_WAIT_PERIOD
milliseconds after the reception of the first bytes on the port. This is the only time a
forced update is performed when serial communications are in use.
A forced update uses the following logic to update the connection status:
• Assume that we are connected.
• If IPROP_CONN_STATUS_CALC has the USE_ERROR_COUNT flag set, then:

– If the error count has incremented since the last snapshot, set the connection
status to disconnected.
• If IPROP_CONN_STATUS_CALC has the USE_BYTES_RX flag set, then:
– If ProtocolPak has not received any bytes since the last snapshot, set the
connection status to disconnected.
• If IPROP_CONN_STATUS_CALC has the USE_BYTES_TX flag set, then:
– If ProtocolPak has not transmitted any bytes since the last snapshot, set the
• If neither an event tick nor a static read tick nor a static write tick has occurred since
the last snapshot, set the connection status to disconnected. That is, if there has
been no successful event read, static read, or static write in the
IPROP_CONN_STATUS_INIT_WAIT_PERIOD milliseconds since the reception of
the first bytes on the port, set the connection status to disconnected.
Note: This last test means that you only needed to have processed either an event
read or a static read or a static write for this test to succeed.
In general, it is unrealistic to expect multiple operation types to occur in the first

IPROP_CONN_STATUS_INIT_WAIT_PERIOD milliseconds after the reception of the
first bytes on the port. This logic is relaxed for forced updates but is stricter for periodic
updates.
A periodic update is performed occasionally after a forced update at the interval
specified by the parameter IPROP_CONN_STATUS_UPDATE_PERIOD. In the
absence of a forced update, periodic updates still occur at the period specified by
A periodic update uses the following logic to update the connection status:
• Assume that we are connected.
• If IPROP_CONN_STATUS_CALC has the USE_ERROR_COUNT flag set, then:
– If the error count has incremented since the last snapshot, set the connection
status to disconnected.
• If IPROP_CONN_STATUS_CALC has the USE_BYTES_RX flag set, then:
– If ProtocolPak has not received any bytes since the last snapshot, set the
• If IPROP_CONN_STATUS_CALC has the USE_BYTES_TX flag set, then:
– If ProtocolPak has not transmitted any bytes since the last snapshot, set the
• If IPROP_CONN_STATUS_CALC has the USE_EVENT_TICK flag set, then:
– If ProtocolPak has not processed an event read since the last snapshot, set the

• If IPROP_CONN_STATUS_CALC has the USE_READ_TICK flag set, then:
– If ProtocolPak has not processed a static read since the last snapshot, set the
• If IPROP_CONN_STATUS_CALC has the USE_WRITE_TICK flag set, then:
– If ProtocolPak has not processed a static write since the last snapshot, set the
9.5.2 Network Communications

Upon startup of the application, the connection status is set to 0 (disconnected).
Since network communications (using sockets) incorporates the concept of “link layer
connectivity” (whether a socket connection is established or not), it is possible to
shortcut all of the logic inherent in the forced and periodic updates under the condition
where a socket connection is not currently established with the remote station. That is, if
there is no established socket with the remote station, set the connection status to
disconnected and disable both forced and periodic updates.
However, if a socket connection is established, the logic used in the forced and periodic
updates is enabled. In such a case, a forced update is performed
IPROP_CONN_STATUS_INIT_WAIT_PERIOD milliseconds after the establishment of
a socket connection with the remote station. Note that a forced update occurs every
time after a socket is established. Contrast this with the forced update for serial
communications, which only occurs once in the life of the program.
A forced update when using network communications uses the same logic as a forced
update when using serial communications (for a description of the logic, see section
9.5.1 Serial Communications).
A periodic update is performed occasionally after a forced update at the interval
specified by the parameter IPROP_CONN_STATUS_UPDATE_PERIOD. In the
absence of a forced update, periodic updates still occur at the period specified by
Periodic updates when using network communications use the same logic as periodic
updates when using serial communications (for a description of the logic, see section
9.5.1 Serial Communications).
9.5.3 Display Indications

The connection status is manifest in two indications on the xx2smp displays. First, if any
of the ProtocolPak controls loaded by xx2smp are reporting a connection status of
disconnected, then the text “DISCONNECTED” is displayed in the title bar of the
xx2smp main window.
Second, the line representing the remote station interface in the xx2smp diagnostics
window is colored red if the corresponding ProtocolPak control is reporting a connection

status of disconnected. If the connection status is reported as connected, the line is
colored black.
9.5.4 Database Storage of Indicators

In addition to being displayed in the xx2smp windows (in the manner specified in section
9.5.3 Display Indications), the connection status can also be written to a measurement
in the SCADA database via the creation of the “Status” data set (this is discussed in
greater detail in section 9.7.12 xx2smp Status Data Set). The creation of this data set is
optional.
9.5.5 Examples and Operational Notes

The default settings of the parameters used to configure the connection status logic are
as follows:
• IPROP_CONN_STATUS_CALC = 31 (0x1F) (i.e., the following flags are used by
default: USE_ERROR_COUNT, USE_BYTES_RX, USE_BYTES_TX,
USE_EVENT_TICK, USE_READ_TICK)
• IPROP_CONN_STATUS_UPDATE_PERIOD = 15000 ms
• IPROP_CONN_STATUS_INIT_WAIT_PERIOD = 3000 ms
Note that the default setting for IPROP_CONN_STATUS_CALC differs from that given
above when IEC101/104 is in use (for further information, refer to the description of the
parameter IPROP_CONN_STATUS_CALC in section 9.7.3 xx2smp Master Data Set).
Consider the case where DNP is in use with network communications. Assume that the
remote station is polling for Class 0 data (only) at a period of two seconds. Upon
startup, the connection status is set to disconnected. Subsequently, the remote station
establishes a socket with ProtocolPak and performs its first Class 0 poll. Three seconds
after the socket establishment, a forced update is performed. Assuming that there have
been no errors and that the first Class 0 poll has completed successfully, the forced
update sets the connection status to connected. The relaxed logic used with a forced
update (with the event, read, and write tick indicators) means that you need only have
received one of these requests during the first three seconds after connection
establishment in order for the connection status to be set to connected.
Now, presume that the Class 0 polls continue. In such a case, a periodic update is
performed 15 seconds after a forced update (18 seconds after the socket was
established). Considering the default setting of IPROP_CONN_STATUS_CALC and the
fact that you are only performing static reads (Class 0 polls), it is clear that the
connection is now marked as disconnected. This is because the default setting of
IPROP_CONN_STATUS_CALC requires you to have both an event tick and a read tick
in each snapshot. Since you did not receive an event tick in the last snapshot, the
connection is marked as disconnected.

This is just one example of a case where the connection can be marked as
disconnected when communications are in fact operational. For this reason, you must
carefully consider both the frequency and the type of communications and set the
aforementioned parameters appropriately. In this case, the Bytes Rx and Bytes Tx
counts are incrementing and the connection is marked as disconnected.
In the above example, if you want the connection status to be marked as connected and
the remote station is only sending Class 0 (static) polls, you need to remove the
USE_EVENT_TICK flag from the IPROP_CONN_STATUS_CALC parameter.
Consider an example similar to the one above, where you have removed the
USE_EVENT_TICK flag from the IPROP_CONN_STATUS_CALC parameter. Now
assume that the remote station is only polling for Class 0 data every 60 seconds. In
such a case, it is desirable to set the periodic update frequency
(IPROP_CONN_STATUS_UPDATE_PERIOD) to a value greater than 60 seconds (say,
65 or 70 seconds). If this is not done, the status is marked as disconnected 15 seconds
after a forced update following the establishment of a socket.
If you are using secure communications, it may happen that you need to increment the
IPROP_CONN_STATUS_INIT_WAIT_PERIOD period. This can be required because
the handshake that occurs upon connection establishment can take 1–2 seconds to
complete (and sometimes longer). In such a case, if the first application layer request
does not arrive in IPROP_CONN_STATUS_INIT_WAIT_PERIOD milliseconds after the
establishment of a socket, the connection is marked as disconnected when this may not
truly reflect the actual conditions. Incrementing
IPROP_CONN_STATUS_INIT_WAIT_PERIOD resolves this problem.
Note that the default setting for IPROP_CONN_STATUS_CALC differs from that given
above when IEC101/104 is in use (for further information, refer to the description of the
parameter IPROP_CONN_STATUS_CALC in section 9.7.3 xx2smp Master Data Set).
9.6 Data Source Configuration (Measurements)

xx2smp uses a data source in SCADA.exe to read and write measurements and
execute controls. The data source is assigned Read access to the main xx2smp data
set tree and Write access to the xx2smp status data set tree. The name of the data
source is used in the command-line argument “-n”.
Note that the Remote check box is used for local/remote interlocking. If the xx2smp
application is interfacing with a control center, it can be useful to check this box,
indicating that the data source is to be considered remote in the context of local/remote
interlocking schemes.

Figure 17. xx2smp Data Source Example

Figure 18. xx2smp Data Source Example
9.7 Data Set Configuration

Configuration data can be presented to the SCADA server application from one of three
sources. These sources include data set configuration in the SCADA server application,
a text file, and the measurement tree in the SCADA server application.
The recommended means to configure xx2smp is through SCADA data sets. The text
file and measurement tree modes are strongly deprecated.
The data set configuration mode is the default, and it can be specified with the “-d”
command-line argument (for data set modeling details, refer to “Data Set Dialog Box” in
the e-terracontrol Reference Manual: Applications).

The data set hierarchy for the xx2smp application is illustrated below:
Figure 19. xx2smp Data Set Hierarchy
Most data sets include the facility to accept a number of parameters. These parameters
are grouped into different data sets according to their function. All parameters beginning
with “IPROP_” or “IOC_” are passed from xx2smp to ProtocolPak. These parameters
are used by ProtocolPak to customize certain aspects of its functionality. Parameters
without either of these designations are used solely by xx2smp.
Some parameters do not have defaults and must be explicitly specified. However, the
majority of parameters have sensible default values. This means that, in many cases, it
is possible to configure a system with only a very small number of parameters explicitly
specified. In the following sections, all defaults are given.
Unless otherwise specified, all parameters and values are case-sensitive. All numeric
values should be supplied in decimal. String values should not be enclosed in double
quotation marks.
Caution: The data set type names configured in the SCADA database must exactly
match the data set type names given in the following sections.

9.7.1 xx2smp Data Set Types
xx2smp data set types are used by xx2smp and e-terrabrowser. In e-terrabrowser, the
xx2smp Communication Status display uses the xx2smp data set types to show the
connection state of the xx2smp master if an xx2smp status data set tree is defined.
9.7.1.1 xx2smpDS Data Set Type

The xx2smpDS data set type display does not have the Dual States check box selected.
Figure 20. xx2smpDS Data Set Type Example

9.7.1.2 xx2smpDS_Status Data Set Type
The xx2smpDS_Status data set type display does not have the Dual States check box
selected.
Figure 21. xx2smpDS_Status Data Set Type Example

9.7.1.3 xx2smpMasterDS Data Set Type
The xx2smpMasterDS data set type display does not have the Dual States check box
selected.
Figure 22. xx2smpMasterDS Data Set Type Example

9.7.1.4 xx2smpCommsDS Data Set Type
The xx2smpCommsDS data set type display does not have the Dual States check box
selected.
Figure 23. xx2smpCommsDS Data Set Type Example

9.7.1.5 StatusDS Data Set Type
The StatusDS data set type display does not have the Dual States check box selected.
Figure 24. StatusDS Data Set Type Example

9.7.2 xx2smp Data Set
The xx2smp data set (of type xx2smpDS) should be configured similarly to that shown
in Figure 25.
No xx2smp data set parameters need to be configured for xx2smp. No data items need
to be supplied in this data set.
Figure 25. xx2smp Data Set Example
9.7.3 xx2smp Master Data Set

An example of a typical xx2smp master data set (of type xx2smpMasterDS) is shown in
Figure 26. No data items need to be supplied in this data set.
Figure 26. xx2smp Master Data Set Example

In this data set, the following parameters can be configured:
• IPROP_PROTOCOL: Specifies the protocol that is to be used. Options are:
– DNP
– IEC
– GYR
The ProtocolPak ActiveX control currently supports the DNP, IEC101, IEC104, and
Telegyr 8979 protocols. Note that “IEC” should be specified for either IEC101 or
IEC104. The parameter IPROP_IEC_DATALINK_TYPE (in the protocol data set) is
used to select between IEC101 and IEC104.
Further protocols can be added in the future.
Default = DNP
• IPROP_COMMSTYPE: Specifies the type of communications to use. Options are:
– SERIAL
– NETWORK
– SECURENETWORK
Default = SERIAL
• IPROP_ROLE: Specifies the role of the local station. Options are:
– MASTER
– SLAVE
Neither xx2smp nor ProtocolPak presently support operations in master mode. To
that end, this parameter is not used for any substantive purpose. Therefore, it is
purely optional as to whether it is provided.
Default = SLAVE
• IPROP_DEBUG_LEVEL: Specifies the level of tracing that the ProtocolPak ActiveX
control performs. Note that this only affects the traces sent to the ProtocolPak log
files. It is distinct from the “-l” xx2smp command-line argument, which can be used to
set the logging level for the xx2smp log files. Options are:
– 0 = None
– 1 = Fatal
– 2 = Fatal and Error
– 3 = Fatal, Error, and Warning
– 4 = Fatal, Error, Warning, and Informational
During normal operations, IPROP_DEBUG_LEVEL should generally be set to 2.
During debugging or troubleshooting, it can be useful to raise it to 4 in order to
obtain more-detailed information in the ProtocolPak log files. This information

includes dumps of the message fragments (among many other things). Be warned
that many messages are logged when the level is set to 4.
If IPROP_DEBUG_LEVEL is set to 0, no ProtocolPak log files whatsoever are
created on disk.
It is not recommended to set the debug level to either 1 or 3. Setting the debug level
to 1 can cause important error messages to be missed, and setting the debug level
to 3 produces little more information than when it is set to 2.
Default = 2
• IPROP_DEBUG_AREAS: Specifies which functional areas in the ProtocolPak
ActiveX control are to send traces to the log file. This parameter is implemented as a
bit mask. Its value can be set according to flags listed below. The flags can be
bitwise ORed together in order to receive traces from multiple areas. The allowable
flags are:
– 0x0010 (DEBUG_NETWORK)
– 0x0020 (DEBUG_PROTOCOL)
– 0x0040 (DEBUG_DAC)
– 0x0080 (DEBUG_GPT)
– 0x0100 (DEBUG_SOK)
– 0x0200 (DEBUG_TRN)
– 0x0400 (DEBUG_INIT)
– 0x0800 (DEBUG_DLL)
– 0x1000 (DEBUG_TRL)
– 0x2000 (DEBUG_APL)
– 0x4000 (DEBUG_NL)
– 0x8000 (DEBUG_MORE)
Each functional area of the ProtocolPak ActiveX control logs messages with an
indicator specific to its area. If the corresponding flag is set in the
IPROP_DEBUG_AREAS parameter, the message is traced to a file; otherwise, it is
not traced to a file. The value for IPROP_DEBUG_AREAS must be supplied in
decimal format.
This parameter is provided for advanced users only. Most users should leave it set
to the default.
Default = 65520 (0xFFF0) (All areas)
• IPROP_DEBUG_FOLDER: Specifies the folder in which the ProtocolPak ActiveX
control is to write its log files. Note that this only affects the ProtocolPak log files. It is
distinct from the “-z” xx2smp command-line argument, which can be used to set the
folder in which the xx2smp log files are to be written.

If the IPROP_DEBUG_FOLDER parameter is not provided, ProtocolPak log files are
written to the current working directory of the xx2smp application.
An absolute path name must be provided — e.g.,
D:\MyDir\MySubDir
A trailing “\” at the end of the path name is optional. Relative path names are not
supported.
Default = “ ” (an empty string, which means that files are written to the current
working directory)
• IPROP_AUDIT_LOG_MAX_FILE_SIZE: Specifies the maximum size that a
ProtocolPak log file can reach before it is closed and a new file is opened (in
bytes) — i.e., before a log file “rollover” occurs.
Note that this only affects the ProtocolPak log files. It is distinct from the “-S” xx2smp
command-line argument, which is used to set the rollover size for xx2smp log files.
Default = 524288 bytes (512k)
• IPROP_TIME_SYNC: Specifies whether or not the local station accepts time
synchronization requests from the remote station. Options are:
– 0 = Disabled
– 1 = Enabled
If this parameter is set to 1 and a time synchronization command is received from
the remote station, the time contained in this command is used to set the clock on
the machine on which xx2smp is running. If set to 0, the time synchronization
command is ignored. This option should be used with care, since the act of changing
the PC time may have ramifications on other applications in operation on the
machine.
Default = 0
• IPROP_TIME_UTC: Specifies the format in which the time is passed from the
remote station in time synchronization commands. Options are:
– 0 = Local time
– 1 = UTC time
It is only relevant to set this parameter if remote time synchronization is enabled (by
setting IPROP_TIME_SYNC to 1).
Default = 0
• IPROP_EVENT_QUEUE_TIME_ORDERED: Specifies whether or not to order the
events in the event queue based on the timestamp associated with each event.
Options are:
– 0 = Event queue ordered based on the sequence of arrival of events
– 1 = Event queue ordered based on the timestamp of each event
Default = 1

• IPROP_EVENT_QUEUE_ROLLOVER: Specifies the behavior that is to occur when
the event queue maintained by ProtocolPak is filled. Options are:
– 0 = When a new event arrives and the event queue is full, the new event is
simply discarded.
– 1 = When a new event arrives and the event queue is full, the oldest event is
deleted from the queue and the newly arriving event is added (thus maintaining
the most recent events in the queue).
A common situation in which the event queue can become filled is if the remote
station is unavailable. In such circumstances, events can accumulate at the local
station since the remote station is not polling for these events (and, therefore, they
remain in the queue).
Default = 1
• IPROP_CONN_STATUS_CALC: Specifies the system status indicators that are to
be used when updating the ProtocolPak Connected flag, as reported to xx2smp (for
more information about this parameter and the manner in which it is used, see
section 9.5 ProtocolPak Connection Status Indicator).
Implemented as a bit mask. If multiple flags are required, the requisite flags should
be bitwise ORed together. If a particular flag is set, it indicates that the
corresponding system indicator is used in the logic used to set the Connected flag.
The flags that can be set are as follows:
– 0x01 = USE_ERROR_COUNT – Use the error count during the last
IPROP_CONN_STATUS_UPDATE_PERIOD ms when updating the Connected
flag. If the error count has incremented in this period, the connection is marked
as disconnected.
– 0x02 = USE_BYTES_RX – Use the bytes received during the last
flag. If no bytes have been received in this period, the connection is marked as
disconnected.
– 0x04 = USE_BYTES_TX – Use the bytes transmitted during the last
flag. If no bytes have been transmitted in this period, the connection is marked as
disconnected.
– 0x08 = USE_EVENT_TICK – Use the event poll indicator during the last
flag. If no event poll has occurred during this period, the connection is marked as
disconnected — i.e., if DNP is in use, a Class 1 poll sets the event poll indicator
and thus satisfies the condition for a connected link with the remote station.
– 0x10 = USE_READ_TICK – Use the static read indicator during the last
flag. If no static read has occurred during this period, the connection is marked
as disconnected — i.e., if DNP is in use, a Class 0 poll sets the static read

indicator and thus satisfies the condition for a connected link with the remote
station.
– 0x20 = USE_WRITE_TICK – Use the static write indicator during the last
flag. If no static write has occurred during this period, the connection is marked
as disconnected. Importantly, the static write indicator is not set after a write to
the port but rather after a control or setpoint operation is received — i.e., if DNP
is in use, a “Direct Operate Relay” operation sets the static write indicator and
thus satisfies the condition for a connected link with the remote station.
Protocols such as DNP 3 perform periodic event polls, since there is no means for
the slave to communicate to the remote station that there are pending events to be
transmitted (as part of the response to a static read). However, protocols such as
IEC include such a mechanism (the ACD bit). This means that IEC master stations
need not periodically poll for events; rather, they only poll for events when there are
events available (as indicated by the ACD bit). For this reason, when IEC is in use,
the USE_EVENT_TICK indicator is neither relevant nor useful (since it presumes
that the remote station polls for events periodically). Therefore, the
USE_EVENT_TICK indicator is always disabled when IEC is in use. However, it
remains enabled by default for all other protocols.
– Default = 31 (0x1F) for all protocols except IEC101/104
– Default = 23 (0x17) for IEC101/104
The logic enabled by the default settings should be acceptable in most
circumstances. For protocols other than IEC101/104, the default uses all flags
except USE_WRITE_TICK. For IEC101/104, the default uses all flags except
USE_WRITE_TICK and USE_EVENT_TICK.
• IPROP_CONN_STATUS_UPDATE_PERIOD: Specifies the interval when the
connection status of the ProtocolPak control is to be checked (in milliseconds).
The flags specified by the IPROP_CONN_STATUS_CALC parameter are used to
determine the logic used to set the connection status indicator (for more information
about this parameter and the manner in which it is used, refer to section 9.5
ProtocolPak Connection Status Indicator).
The minimum acceptable value for this parameter is 4000 milliseconds. It is
generally inappropriate to set this value to anything less than the default (unless the
remote station is polling at a high frequency and you are concerned with updating
the connection status frequently).
Default = 15000 milliseconds (15 seconds)
• IPROP_CONN_STATUS_INIT_WAIT_PERIOD: Specifies the period to wait before
updating the ProtocolPak Connection Status flag after the initial indications of a
connection establishment with the remote station (in milliseconds). This period
provides a short time for communications to occur before updating the Connected
flag (for more information about this parameter and the manner in which it is used,
refer to section 9.5 ProtocolPak Connection Status Indicator).

The minimum acceptable value for this parameter is 2000 milliseconds.
Default = 3000 milliseconds (3 seconds)
• IPROP_BINARY_OUTPUT_SBO_ENABLED: Specifies whether Select Before
Operate (SBO) controls are accepted from the remote station. Options are:
– 0 = Disabled
– 1 = Enabled
If an SBO control is received and SBO controls are disabled, an error is returned to
the remote station and the control is not executed.
Default = 1
• IPROP_BINARY_OUTPUT_DIRECT_OPERATE_ENABLED: Specifies whether
Direct Operate controls are accepted from the remote station. Options are:
– 0 = Disabled
– 1 = Enabled
If a Direct Operate control is received and Direct Operate controls are disabled, an
error is returned to the remote station and the control is not executed.
Default = 1
• IPROP_BINARY_OUTPUT_DIRECT_OPERATE_NO_ACK_ENABLED: Specifies
whether Direct Operate No Ack controls are accepted from the remote station.
Options are:
– 0 = Disabled
– 1 = Enabled
If a Direct Operate No Ack control is received and Direct Operate No Ack controls
are disabled, an error is returned to the remote station and the control is not
executed.
Default = 1
• IPROP_ANALOG_OUTPUT_SBO_ENABLED: Specifies whether Select Before
Operate (SBO) controls on analog outputs (setpoints) are accepted from the remote
station. Options are:
– 0 = Disabled
– 1 = Enabled
If an SBO analog output is received and SBO analog outputs are disabled, an error
is returned to the remote station and the analog output is not sent.
Default = 1
• IPROP_ANALOG_OUTPUT_DIRECT_OPERATE_ENABLED: Specifies whether
Direct Operate analog outputs are accepted from the remote station. Options are:
– 0 = Disabled

– 1 = Enabled
If a Direct Operate analog output is received and Direct Operate analog outputs are
disabled, an error is returned to the remote station and the analog output is not sent.
Default = 1
• IPROP_ANALOG_OUTPUT_DIRECT_OPERATE_NO_ACK_ENABLED: Specifies
whether Direct Operate No Ack analog outputs are accepted from the remote
– 0 = Disabled
– 1 = Enabled
If a Direct Operate No Ack analog output is received and Direct Operate No Ack
analog outputs are disabled, an error is returned to the remote station and the
analog output is not sent.
Default = 1
• IPROP_BINARY_OUTPUT_SBO_ARM_TIMER: Specifies the maximum select to
execute delay time for SBO controls (in milliseconds).
Default = 2000 (2 seconds)
• IPROP_ANALOG_OUTPUT_SBO_ARM_TIMER: Specifies the maximum select to
execute delay time for analog outputs (setpoints) (in milliseconds).
• IPROP_EVENT_QUEUE_LENGTH: Specifies the length of the queue used to store
protocol-specific events. A single queue is used to store protocol-specific events for
all object types (binaries, analogs, etc.). The length of this queue must be sized
according to:
– The requirements for storage of events (whether it is acceptable to lose events if
the remote station fails to poll for a period of time and the event buffer overflows)
– The rate of change of points in the field
– The rate the master is polling for events
In most cases, the default value should be acceptable.
Default = 500
• IPROP_CONTROL_RESPONSE_WAIT_PERIOD: Specifies the period of time to
wait for a control response from SCADA after sending a control (or setpoint) request
to SCADA. This period allows for the case where a rapid response from SCADA is
received in response to a control or setpoint request (which generally occurs in the
case of an error). In such a case, the error is then returned immediately to the
remote station.
It is important to note that communication with the remote station is blocked during
this period of time. For this reason, the value of this parameter is limited to a

maximum of 300 milliseconds (for a comprehensive description of the manner in
which this parameter is used, refer to section 9.11 Control Response Notifications).
Default = 300 (milliseconds)
Maximum = 300 (milliseconds)
9.7.4 xx2smp Comms Data Set

An example of a typical xx2smp comms data set (of type xx2smpCommsDS) is shown
in Figure 27. No data items need to be supplied in this data set.
Figure 27. xx2smp Comms Data Set Example
A number of parameters can be configured in this data set. Some of these parameters
are specific to serial communications, some are specific to network communications,
and some are common to both serial and network communications.
The parameters are divided into the three categories listed below. In addition, each
parameter is classified according to its “mode”. This classification follows the default
value for the parameter. The “mode” can be “Bit”, “Byte”, or “Both”. The “mode”
represents whether this parameter is applicable for only bit communications, only byte
communications, or both bit and byte communications. Since ProtocolPak does not
currently support any bit protocols, there is no need to ever set any parameters whose
“mode” is “Bit”.
For serial communications, the following parameters can be configured:
• IOC_MODE: Specifies the communications driver operating mode (bit or byte).
Options are:
– 0 = Bit
– 1 = Byte

ProtocolPak does not currently support any bit protocols, so there is no need to
modify this parameter from its default.
Default = 1
Mode = N/A
• IOC_LINEMODE: Specifies the line mode. Options are:
– 0 = Dedicated
– 1 = Dial-up
ProtocolPak does not currently support dial-up mode, so there is no need to modify
this parameter from its default.
Default = 0
Mode = Both
• IOC_SWITCHED: Specifies whether the line is dedicated or non-dedicated. Options
are:
– 0 = Dedicated
– 1 = Non-dedicated
Default = 0
Mode = Both
• IOC_BAUDRATE: Specifies the COM port baud rate. Options are:
– 110
– 300
– 600
– 1200
– 2400
– 4800
– 9600
– 14400
– 19200
– 38400
– 56000
– 57600
– 115200
– 128000
– 256000
Default = 9600
Mode = Both

• IOC_PRE_TRANSMISSION_MARKS: Specifies the pre-transmission marks (bit
protocols only). The value should be specified in decimal.
Default = 0
Mode = Bit
• IOC_PRE_TRANSMISSION_DELAY: Specifies the pre-transmission delay in
milliseconds (bit protocols only).
Default = 80
Mode = Bit
• IOC_POST_TRANSMISSION_MARKS: Specifies the post-transmission marks (bit
protocols only). The value should be specified in decimal.
Default = 0
Mode = Bit
• IOC_POST_TRANSMISSION_DELAY: Specifies the post-transmission delay in
milliseconds (bit protocols only).
Default = 40
Mode = Bit
• IOC_SQUELCH: Specifies the carrier “squelch”. This parameter is currently unused,
so it need not be modified from its default.
Default = 0
Mode = Both
• IOC_TXCARRIER: Specifies the transmit carrier. Options are:
– 0 = Constant
– 1 = Switched
– 2 = Soft (switched in software, not hardware)
Default = 1
Mode = Both

• IOC_RXCARRIER: Specifies the receive carrier. Options are:
– 0 = Constant
– 1 = Switched
– 2 = Soft (switched in software, not hardware)
Default = 1
Mode = Both
• IOC_PARITY: Specifies the port parity. Options are:
– 0 = None
– 1 = Odd
– 2 = Even
Default = 0
Mode = Byte
• IOC_DATALEN: Specifies the length of the data frame in bits. Zero indicates a bit
protocol, non-zero indicates a byte protocol. Since ProtocolPak does not currently
support any bit protocols, there is no need to set this to 0. Options are:
– 4
– 5
– 6
– 7
– 8
Default = 8
Mode = Byte
• IOC_STOPBITS: Specifies the number of stop bits. Options are:
– 1
– 2
Default = 1
Mode = Byte
• IOC_EVTCHAR: Specifies the sync character (bit protocols only). The value should
be specified in decimal.
Default = 0
Mode = Bit
• IOC_IDLE: Specifies the line idle character (bit protocols only). The value should be
supplied in decimal.

Default = 0
Mode = Bit
• IOC_REDUNDANT: Specifies whether or not redundant ports should be used.
Options are:
– 0 = No redundant ports
– 1 = Redundant ports
ProtocolPak does not presently support redundant ports, so there is no need to
change this parameter from its default.
Default = 0
Mode = Both
• IOC_INTER_CHARACTER_TIMEOUT: Specifies the inter-character timeout in
milliseconds. This parameter is not used with any protocols presently supported by
ProtocolPak; therefore, it need not be modified from its default.
Default = 25
Mode = Byte
• IOC_BAUD_RATE_MULTIPLIER: Specifies a baud rate multiplier (which is used to
over-sample the input port). This parameter is not used with any protocols presently
supported by ProtocolPak; therefore, it need not be modified from its default.
Default = 1
Mode = Byte
For network communications, the following parameters can be configured:
• IOC_UDP: Specifies the network transport provider that is to be used. Options are:
– 0 = Streams (TCP)
– 1 = Datagrams (UDP)
Notably, streams must be used when secure communications are in use (since SSL
requires a reliable transport).
Default = 0 (TCP)
Mode = Byte
• IOC_SERVERNAME: Specifies the data server network address (or name) on which
the local station is to listen for incoming connections. The default setting (a NULL
string) directs ProtocolPak to listen on “localhost”.
Ordinarily, the use of this parameter should only be required on machines with
multiple network adapters where the user wants to have ProtocolPak listen on a

specific adapter. Either a PC name or an IP address can be supplied — e.g.,
121.222.123.54
When ProtocolPak is configured as a slave and IOC_SERVERNAME is NULL,
ProtocolPak listens on localhost. If IOC_SERVERNAME is not NULL, ProtocolPak
listens on whatever address is supplied.
When ProtocolPak is configured as a master and IOC_SERVERNAME is not NULL,
ProtocolPak connects to the supplied address.
(ProtocolPak does not presently support master mode operations.)
Default = “ ”
Mode = Byte
• IOC_MAX_CONNECTIONS: Specifies the maximum number of simultaneously
open network connections that ProtocolPak can maintain concurrently. ProtocolPak
does not currently support more than one concurrent network connection per control;
therefore, this parameter should not be modified from its default.
Default = 10
Mode = Byte
• IOC_NETWORK_COMMS_LOST_TIMEOUT: Specifies the length of time after
which an established network connection is closed if there have been no application-
level messages received from the remote station during this period of time (in
milliseconds).
This is necessary to avoid a problem with sockets whereby it is possible for a server
(ProtocolPak) to maintain an open socket to a client that has abruptly failed. Many
master stations use a periodicity of 60 seconds for static polls; therefore, the default
timeout is set to just over this value (70 seconds).
This parameter is only used when streams are in use (IOC_UDP=0). If IOC_UDP=1,
then datagrams (UDP) are in use.
UDP is a connectionless protocol, so the aforementioned considerations do not
apply and the setting of this parameter is irrelevant.
Mode = Byte
For both serial and network communications, the following parameters are common:
• IOC_HANDSHAKE: Specifies the line handshaking mode. Options are:
– 0 = No handshaking
– 1 = RTS/CTS handshaking
ProtocolPak does not presently support any protocols that make use of this
parameter. Therefore, there is no need to modify it from its default.
Default = 0

Mode = Both
• IOC_INTRA_MESSAGE_DELAY: Specifies the intra-message delay in
milliseconds. This is the amount of time required for the line to settle.
Default = 100
Mode = Both
• IOC_INTRA_MESSAGE_TIMEOUT: Specifies the intra-message timeout in
milliseconds.
Default = 0
Mode = Byte
• IOC_INTER_MESSAGE_DELAY: Specifies the inter-message delay in
milliseconds.
Default = 100
Mode = Both
• IOC_INTER_MESSAGE_TIMEOUT: Specifies the inter-message timeout in
milliseconds. If the timeout is exceeded, a response is not sent and an error is
returned. A value of 0 disables the timeout.
Default = 0
Mode = Byte
• IOC_TXSIZE: Specifies the maximum transmit size. ProtocolPak does not currently
support any bit protocols, so there is no need to modify this parameter from its
default.
Default = 0
Mode = Bit
• IOC_SMART: Specifies whether the intelligent communications layer is to be used.
Options are:
– 0 = Normal comms
– 1 = Intelligent comms
This intelligent comms layer is presently unsupported, so this parameter should not
be modified from its default.
Default = 0
Mode = Byte
• IOC_HARDWARE_TYPE: Specifies the hardware type.
Default = 0

Mode = Both
• IOC_PORT: Specifies the port that is to be used. For serial communications, this is
the number of the serial port to use — e.g., 2 for COM2. For network
communications, this is the port used to establish connections between client and
server — e.g., DNP over IP generally uses port 20000, IEC104 generally uses
port 2404.
Default = 2 (corresponds to COM2 if serial communications are in use or port 2 if
network communications are in use)
Mode = Byte
• IOC_HALFDUPLEX: Specifies whether half-duplex communications are to be used.
Options are:
– 0 = No half duplex
– 1 = Half duplex
Default = 0
Mode = Both
• IOC_INVERT: Specifies whether inverted communications are to be used. Options
are:
– 0 = No inverted communications
– 1 = Inverted communications
Default = 0
Mode = Byte
The xx2smp comms data set is also used to configure aspects related to the operation
of the protocol that has been selected. Selections of parameters are provided for each
supported protocol. Each parameter has a sensible default. If you are unclear about the
specific purpose of a parameter, it is strongly recommended that you accept the default
setting. In most cases, the defaults are adequate.
Note: All numeric values must be supplied in decimal.
The remainder of this section presents the parameters that can be used for the DNP,
IEC101/104, and Telegyr 8979 protocols.

9.7.4.1 DNP Parameters
Table 13 can be used as a quick reference for the available DNP parameters. Detailed
descriptions of these parameters are given following the table.
Table 13. DNP Parameters Quick Reference

Parameter Default
IPROP_DNP_UNSOLICITED_MODE 0
IPROP_DNP_RX_FRAGMENT_SIZE 2048
IPROP_DNP_TX_FRAGMENT_SIZE 8192
IPROP_DNP_IIN_CONFIRM 2049
IPROP_DNP_APPLICATION_CONFIRM 2
IPROP_DNP_UNSOLICITED_CONFIRM 7
IPROP_DNP_APPLICATION_RETRY 0
IPROP_DNP_UNSOLICITED_RETRY 0
IPROP_DNP_UNSOLICITED_STARTUP 3
IPROP_DNP_UNSOLICITED_DATA 1
IPROP_DNP_APPLICATION_TIMEOUT 6000
IPROP_DNP_UNSOLICITED_POLL_FREQUENCY 2000
IPROP_DNP_DEGRADED_TIMEOUT 10000
IPROP_DNP_DEFAULT_VARIATION[DFLT_NOT_SUPPORTED] 0
IPROP_DNP_DEFAULT_VARIATION[DFLT_BI] 2
IPROP_DNP_DEFAULT_VARIATION[DFLT_BI_CHG] 1
IPROP_DNP_DEFAULT_VARIATION[DFLT_BI_CHG_TIME] 2
IPROP_DNP_DEFAULT_VARIATION[DFLT_BO] 2
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI] 6
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_DELTA] 8
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_CHG] 2
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_CHG_TIME] 6
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_CHG_DELTA] 4
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_CHG_DELTA_TIME] 8
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_FRZ] 10
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_FRZ_DELTA] 12
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_FRZ_CHG] 2
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_FRZ_CHG_TIME] 6
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_FRZ_CHG_DELTA] 4

Parameter Default
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_FRZ_CHG_DELTA_TIME] 8
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI] 2
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_FLOAT] 5
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_LONG_FLOAT] 6
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_CHG] 2
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_CHG_TIME] 4
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_CHG_FLOAT] 5
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_CHG_FLOAT_TIME] 7
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_CHG_LONG_FLOAT] 6
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_CHG_LONG_FLOAT_TIME] 8
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_FRZ] 6
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_FRZ_FLOAT] 7
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_FRZ_LONG_FLOAT] 8
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_CHG_FRZ] 2
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_CHG_FRZ_TIME] 4
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_CHG_FRZ_FLOAT] 5
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_CHG_FRZ_FLOAT_TIME] 7
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_CHG_FRZ_LONG_FLOAT] 6
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_CHG_FRZ_LONG_FLOAT_TIME] 8
IPROP_DNP_DEFAULT_VARIATION[DFLT_AO] 2
IPROP_DNP_DEFAULT_VARIATION[DFLT_AO_FLOAT] 3
IPROP_DNP_DEFAULT_VARIATION[DFLT_AO_LONG_FLOAT] 4
IPROP_DNP_DEFAULT_VARIATION[DFLT_BO_COMMAND] 1
IPROP_DNP_DEFAULT_VARIATION[DFLT_RELAY_COMMAND] 1
IPROP_DNP_DEFAULT_VARIATION[DFLT_AO_COMMAND] 2
IPROP_DNP_DEFAULT_VARIATION[DFLT_STORAGE_OBJECT] 1
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_FRZ_TIME] 6
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_FRZ_DELTA_TIME] 8
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_FRZ_TIME] 4
IPROP_DNP_DEFAULT_VARIATION[DFLT_BI_WITH_STATUS] 2
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_WITH_STATUS] 2
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_FRZ_WITH_STATUS] 2
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_WITH_STATUS] 2
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_FRZ_WITH_STATUS] 2

Parameter Default
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_LONG] 2
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_LONG_WITH_STATUS] 2
IPROP_DNP_DEFAULT_VARIATION[DFLT_AO_LONG] 1
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_CHG_FRZ_LONG] 2
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_CHG_FRZ_LONG_TIME] 4
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_CHG_LONG] 2
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_CHG_LONG_TIME] 4
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_FRZ_LONG] 6
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_FRZ_LONG_TIME] 4
IPROP_DNP_DEFAULT_VARIATION[DFLT_AI_FRZ_LONG_WITH_STATUS] 2
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_FRZ_CHG_LONG] 2
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_FRZ_CHG_LONG_TIME] 6
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_FRZ_CHG_LONG_DELTA] 4
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_FRZ_CHG_LONG_DELTA_TIME] 8
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_CHG_LONG_DELTA_TIME] 8
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_CHG_LONG] 2
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_CHG_LONG_TIME] 6
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_CHG_LONG_DELTA] 4
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_FRZ_LONG] 10
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_FRZ_LONG_TIME] 6
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_FRZ_LONG_DELTA] 12
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_FRZ_LONG_DELTA_TIME] 8
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_FRZ_LONG_WITH_STATUS] 2
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_LONG] 7
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_LONG_DELTA] 8
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_LONG_WITH_STATUS] 1
IPROP_DNP_EVENT_CLASS 0
IPROP_DNP_DATALINK_UNSOLICITED 0
IPROP_DNP_DIRECTION 0
IPROP_DNP_DATALINK_ADDRESS 0
IPROP_DNP_DATALINK_TIMEOUT 4000
IPROP_DNP_DATALINK_RETRY 0
IPROP_DNP_DATALINK_CONFIRM 0
IPROP_DNP_DATALINK_NAK 1

Parameter Default
IPROP_DNP_RESYNC_INTERVAL 3600
IPROP_DNP_TPDU_SIZE 250
IPROP_DNP_APDU_SIZE 2048
IPROP_DNP_UNSOLICITED_TIMEOUT 5000
IPROP_DNP_PARTIAL_RESULTS 0
IPROP_DNP_OBJECT_COUNT 82
IPROP_DNP_SINGLE_FRAGMENT 0
IPROP_DNP_PERSISTENT_PATTERN 0
IPROP_DNP_FILE_NAME_SIZE 128
IPROP_DNP_TEST_LINK 1000
IPROP_DNP_TEST_FUNCTION 0
IPROP_DNP_COLD_START_DELAY 20000
IPROP_DNP_REFRESH_RETRANSMIT 1
IPROP_DNP_MAXIMUM_RELAYS 0
IPROP_DNP_MAXIMUM_ANALOG_OUTPUTS 0
For the DNP protocol, the following parameters can be configured in the protocol data
set:
• IPROP_DNP_UNSOLICITED_MODE: Specifies whether or not DNP unsolicited
mode is to be supported. Options are:
– 0 = No unsolicited support
– 1 = Unsolicited support
When set to 0, ProtocolPak disables unsolicited mode and only reports data when
polled for from the remote station. When set to 1, ProtocolPak enables unsolicited
mode, checks for unreported data at an interval defined by
IPROP_DNP_UNSOLICITED_POLL_FREQUENCY, and reports the data to the
remote station in an unsolicited message.
If unsolicited mode is enabled, the parameter IPROP_DNP_EVENT_CLASS must
be set to 1. Additionally, the appropriate variables must be flagged for inclusion in
unsolicited transmissions via the IPROP_OBJECT_CLASS parameter in the
ScanGroup data set.
Unsolicited mode is presently unsupported, so this parameter should not be modified
from its default.
Default = 0

• IPROP_DNP_RX_FRAGMENT_SIZE: Specifies the maximum size of a solicited
application message fragment that can be accepted from the remote station (in
bytes). This value cannot be less than 249.
Default = 2048 (bytes)
• IPROP_DNP_TX_FRAGMENT_SIZE: Specifies the maximum size of an unsolicited
application message or response message fragment that is sent by ProtocolPak to
the remote station (in bytes). This value cannot be less than 249.
Default = 8192
• IPROP_DNP_IIN_CONFIRM: Specifies which local station indications require
message confirmation upon change in status. Implemented as a bit mask. If multiple
flags are required, the requisite flags should be bitwise ORed together.
ProtocolPak maintains 16 local station indications (status bits) and includes them in
the headers of messages sent to the remote station (responses to
solicited/unsolicited application messages, etc.). If an indication has changed since
the last time ProtocolPak sent a message to the remote station and the
corresponding bit in the IPROP_DNP_IIN_CONFIRM bit mask is set, ProtocolPak
requests confirmation in the next message it sends to the remote station. If all the
bits in the mask are 0, ProtocolPak does not request message confirmation on any
change in indication status.
The flags that can be set are as follows:
– 0x0001 (IIN_ALL_STATIONS) – All stations message received. Set when
ProtocolPak receives a message from the remote station with the destination
address set to the all stations address. Cleared on the next message received or
sent to the remote station.
– 0x0002 (IIN_CLASS_1) – Class 1 data available
– 0x0010 (IIN_TIME_SYNC_REQ) – Time synchronization required. Set when the
device initializes. Cleared when the remote station writes the device clock.
– 0x0020 (IIN_DO_LOCAL) – Not supported
– 0x0040 (IIN_DEVICE_TROUBLE) – Not supported
– 0x0080 (IIN_DEVICE_RESTART) – Device restart. Set when the device starts or
restarts. Cleared when the remote station writes the device restart internal
indications bit (object 80).
– 0x0100 (IIN_FUNC_NOT_IMP) – Function code not implemented. Set when
ProtocolPak receives a function code from the remote station that is not
implemented. Cleared on the next message received or sent to the remote
station.

– 0x0200 (IIN_OBJ_UNKNOWN) – Requested objects unknown. Set when the
local station does not have the specified objects or there are no objects assigned
to the class. Cleared on the next message received or sent to the remote station.
– 0x0400 (IIN_PARAM_ERROR) – Parameters in qualifier, range, or data fields
are out of range or not valid. Set when any of these conditions are true. Cleared
on the next message received or sent to the remote station.
– 0x0800 (IIN_BUFFER_OVERFLOW) – Event buffer overflowed
– 0x1000 (IIN_ALREADY_IN_PROC) – Not implemented
– 0x2000 (IIN_CORRUPT_CONFIG) – Not implemented
– 0x4000 (IIN_RESERVED_1) – Not used
– 0x8000 (IIN_RESERVED_2) – Not used
Default = 2049
The default is equivalent to:
(0x0801) IIN_ALL_STATIONS | IIN_BUFFER_OVERFLOW
• IPROP_DNP_APPLICATION_CONFIRM: Specifies the conditions under which
ProtocolPak requests remote station confirmation of an application message
(application messages include responses to solicited application messages and
unsolicited application messages).
be bitwise ORed together. The flags that can be set are as follows:
– 0x00 = Never
– 0x01 = Always
– 0x02 = If message contains event data
– 0x04 = If message contains indication changes, subject to the value of
IPROP_DNP_IIN_CONFIRM
– 0x08 = If message consists of multiple fragments, confirm all but the last
fragment
Default = 2 (0x02)
• IPROP_DNP_UNSOLICITED_CONFIRM: Specifies the conditions under which
ProtocolPak requests remote station confirmation of an unsolicited message.
– 0x00 = Never
– 0x01 = Always

– 0x08 = If message consists of multiple fragments, confirm all but last fragment
from its default.
Default = 7 (0x07)
• IPROP_DNP_APPLICATION_RETRY: Specifies the number of times ProtocolPak
re-sends an unconfirmed application message before taking a degraded timeout.
Note that DNP slaves in a frequently polled environment should not use application
retries. Therefore, in most cases, this parameter need not be changed from its
default.
Default = 0
• IPROP_DNP_UNSOLICITED_RETRY: Specifies the number of times ProtocolPak
re-sends an unconfirmed unsolicited message.
from its default.
Default = 0
• IPROP_DNP_UNSOLICITED_STARTUP: Specifies the types of data that
ProtocolPak sends in the initial unsolicited startup message. The setting of this
parameter is only relevant if unsolicited mode is enabled (via the parameter
IPROP_DNP_UNSOLICITED_MODE).
– 0x00 = Indications only
– 0x01 = Events and indications
– 0x02 = Static data and indications
– 0x03 = Events, static data, and indications
from its default.
Default = 3 (0x03)
• IPROP_DNP_UNSOLICITED_DATA: Specifies the types of data that ProtocolPak
includes in unsolicited messages. The setting of this parameter is only relevant if
unsolicited mode is enabled (via the parameter
– 0x00 = Indications only

– 0x01 = Indications and events
from its default.
Default = 1 (0x01)
• IPROP_DNP_APPLICATION_TIMEOUT: Specifies the number of milliseconds
ProtocolPak waits for the remote station confirmation of an application message
before re-sending the message (if application retries are enabled).
Default = 6000
• IPROP_DNP_UNSOLICITED_POLL_FREQUENCY: Specifies the frequency
ProtocolPak checks for unreported data (changes in indications or new events) in
milliseconds. If unreported data exists and meets the criteria defined in
IPROP_DNP_UNSOLICITED_DATA, ProtocolPak sends the data to the remote
station in an unsolicited message. The setting of this parameter is only relevant if
unsolicited mode is enabled (via the parameter
from its default.
Default = 2000
• IPROP_DNP_DEGRADED_TIMEOUT: Specifies the number of milliseconds
ProtocolPak delays between retry cycles when seeking confirmation of a message.
The setting of this parameter is only relevant if
IPROP_DNP_APPLICATION_CONFIRM and/or
IPROP_DNP_DATALINK_CONFIRM are configured to request confirmation under
particular circumstances.
The parameters IPROP_DNP_APPLICATION_RETRY and
IPROP_DNP_DATALINK_RETRY define the number of retries in a retry cycle.
Default = 10000
• IPROP_DNP_DEFAULT_VARIATION: Used to customize an array of DNP default
variations that ProtocolPak uses to build responses to commands when the
command does not specify a variation.
This parameter uses a specific format in order to configure the array. The parameter
is used with an array syntax in order to specify a particular element of the array to
modify. If you need to modify multiple elements of the array, the parameter can be
supplied multiple times with the appropriate variation strings.
The array contains a number of elements, each of which has a pre-configured
default variation. If this variation is not acceptable, it can be altered by entering a
parameter string similar to:
IPROP_DNP_DEFAULT_VARIATION[DFLT_PI_CHG_TIME]
The part in the square brackets represents the particular element of the array that is
to be modified — i.e., the object whose default variation is to be modified. The
corresponding value is simply the numeric default variation that is required.
Table 14 provides a list of the variation strings that can be supplied. The table also
provides the default variations as configured in ProtocolPak. The name of each
variation string provides sufficient information to determine the object to which it
applies.
Table 14. ProtocolPak DNP Default Variations

Variation String DNP Default Offset Object Description
Variation Default variation for…
DFLT_BI 2 1 1 Binary input obj.
DFLT_BI_CHG 1 2 2 Binary input change obj.
DFLT_BI_CHG_TIME 2 3 2 Binary input change obj.
DFLT_BO 2 4 10 Binary output obj.
DFLT_PI 6 5 20 Counter input obj.
DFLT_PI_DELTA 8 6 20 Counter input obj. with delta
DFLT_PI_CHG 2 7 22 Counter input change obj.
DFLT_PI_CHG_TIME 6 8 22 Counter input change obj. with time
DFLT_PI_CHG_DELTA 4 9 22 Counter input change obj. with delta
DFLT_PI_CHG_DELTA_TIME 8 10 22 Counter input change obj. with time
with delta
DFLT_PI_FRZ 10 11 21 Counter input obj.
DFLT_PI_FRZ_DELTA 12 12 21 Counter input obj. with delta
DFLT_PI_FRZ_CHG 2 13 23 Counter input change obj.
DFLT_PI_FRZ_CHG_TIME 6 14 23 Frozen counter input change obj.
with time
DFLT_PI_FRZ_CHG_DELTA 4 15 23 Frozen counter input change obj.
with delta
DFLT_PI_FRZ_CHG_DELTA_TIME 8 16 23 Frozen counter input change obj.
with delta with time
DFLT_AI 2 17 30 Analog input obj.
DFLT_AI_FLOAT 5 18 30 Analog input obj. float format
DFLT_AI_LONG_FLOAT 6 19 30 Analog input obj. long float format
DFLT_AI_CHG 2 20 32 Analog input change obj.
DFLT_AI_CHG_TIME 4 21 32 Analog input change obj. with time
DFLT_AI_CHG_FLOAT 5 22 32 Analog input change obj. float
format
DFLT_AI_CHG_FLOAT_TIME 7 23 32 Analog input change obj. float
format with time
DFLT_AI_CHG_LONG_FLOAT 6 24 32 Analog input change obj. long float
format
DFLT_AI_CHG_LONG_FLOAT_TI 8 25 32 Analog input change obj. long float
ME format with time
DFLT_AI_FRZ 6 26 31 Frozen analog input obj.

DFLT_AI_FRZ_FLOAT 7 27 31 Frozen analog input obj. float format
DFLT_AI_FRZ_LONG_FLOAT 8 28 31 Frozen analog input obj. long float
format
DFLT_AI_CHG_FRZ 2 29 33 Frozen analog input change obj.
DFLT_AI_CHG_FRZ_TIME 4 30 33 Frozen analog input change obj.
with time
DFLT_AI_CHG_FRZ_FLOAT 5 31 33 Frozen analog input change obj.
float format
DFLT_AI_CHG_FRZ_FLOAT_TIME 7 32 33 Frozen analog input change obj.
float format with time
DFLT_AI_CHG_FRZ_LONG_FLOA 6 33 33 Frozen analog input change obj.
T long float format
DFLT_AI_CHG_FRZ_LONG_FLOA 8 34 33 Frozen analog input change obj.
T_TIME long float format with time
DFLT_AO 2 35 40 Analog output obj.
DFLT_AO_FLOAT 3 36 40 Analog output obj.float format
DFLT_AO_LONG_FLOAT 4 37 40 Analog output obj.long float format
DFLT_BO_COMMAND 1 38 10 Binary output obj.
DFLT_RELAY_COMMAND 1 39 12 Control block obj.
DFLT_AO_COMMAND 2 40 40 Analog output obj.
DFLT_STORAGE_OBJECT 1 41 81 Storage obj.
DFLT_PI_FRZ_TIME 6 42 21 Frozen counter input obj. with time
DFLT_PI_FRZ_DELTA_TIME 8 43 21 Frozen counter input obj. with delta
with time
DFLT_AI_FRZ_TIME 4 44 31 Frozen analog input obj.
DFLT_BI_WITH_STATUS 2 45 1 Binary input obj. with status
DFLT_PI_WITH_STATUS 2 46 20 Counter input obj. with status
DFLT_PI_FRZ_WITH_STATUS 2 47 21 Frozen counter input obj. with status
DFLT_AI_WITH_STATUS 2 48 30 Analog input obj. with status
DFLT_AI_FRZ_WITH_STATUS 2 49 31 Frozen analog input obj. with status
DFLT_AI_LONG 2 50 30 Analog input obj. long format
DFLT_AI_LONG_WITH_STATUS 2 51 30 Analog input obj. with status
DFLT_AO_LONG 1 52 40 Analog output obj. long format
DFLT_AI_CHG_FRZ_LONG 2 53 33 Frozen analog input change obj.
long format
DFLT_AI_CHG_FRZ_LONG_TIME 4 54 33 Frozen analog input obj. with time
DFLT_AI_CHG_LONG 2 55 32 Analog input obj. long format
DFLT_AI_CHG_LONG_TIME 4 56 32 Analog input obj. long format with
time

DFLT_AI_FRZ_LONG 6 57 31 Frozen analog input obj. long format
DFLT_AI_FRZ_LONG_TIME 4 58 31 Frozen analog input obj. long format
with time
DFLT_AI_FRZ_LONG_WITH_STAT 2 59 31 Frozen analog input obj. long format
US with status
DFLT_PI_FRZ_CHG_LONG 2 60 23 Frozen counter input change obj.
long format with time
DFLT_PI_FRZ_CHG_LONG_TIME 6 61 23 Frozen counter input change obj.
long format with time
DFLT_PI_FRZ_CHG_LONG_DELT 4 62 23 Frozen counter input change obj.
A long format with delta
DFLT_PI_FRZ_CHG_LONG_DELT 8 63 23 Frozen counter input change obj.
A_TIME long format with delta with time
DFLT_PI_CHG_LONG_DELTA_TI 8 64 22 Counter input change obj.long
ME format with delta with time
DFLT_PI_CHG_LONG 2 65 22 Counter input change obj. long
format
DFLT_PI_CHG_LONG_TIME 6 66 22 Counter input change obj. long
format with time
DFLT_PI_CHG_LONG_DELTA 4 67 22 Counter input change obj. long
format with delta
DFLT_PI_FRZ_LONG 10 68 21 Frozen counter input obj. long
format
DFLT_PI_FRZ_LONG_TIME 6 69 21 Frozen counter input obj. long
format with time
DFLT_PI_FRZ_LONG_DELTA 12 70 21 Frozen counter input obj. long
format with delta
DFLT_PI_FRZ_LONG_DELTA_TIM 8 71 21 Frozen counter input obj. long
E format with delta with time
DFLT_PI_FRZ_LONG_WITH_STAT 2 72 21 Frozen counter input obj. long
US format with status
DFLT_PI_LONG 7 73 20 Counter input obj. long format
DFLT_PI_LONG_DELTA 8 74 20 Counter input obj. long format with
delta
DFLT_PI_LONG_WITH_STATUS 1 75 20 Counter input obj. long format with
status
• IPROP_DNP_EVENT_CLASS: Specifies whether ProtocolPak should support

per-variable class assignment. Options are:
– 0 = Not supported
– 1 = Supported

When IPROP_DNP_EVENT_CLASS is set to 0, ProtocolPak assumes that all
variables for all objects (that support events) are assigned to Class 1. This is the
default behavior and is satisfactory in most cases.
When IPROP_DNP_EVENT_CLASS is set to 1, this allows individual variables to be
assigned to any DNP class. In such a case, the parameter IPROP_OBJECT_CLASS
should be supplied one or more times in one or more ScanGroup data sets in order
to specify the desired class assignments (for more information about the
IPROP_OBJECT_CLASS parameter, refer to section 9.7.6 ScanGroup Data Set).
If unsolicited mode has been enabled (via the IPROP_DNP_UNSOLICITED_MODE
parameter), IPROP_DNP_EVENT_CLASS must be set to 1. Additionally, the
appropriate variables must be flagged for inclusion in unsolicited transmissions via
the IPROP_OBJECT_CLASS parameter.
Default = 0
• IPROP_DNP_DATALINK_UNSOLICITED: This parameter is currently unused by
ProtocolPak and need not be modified.
Default = 0
• IPROP_DNP_DIRECTION: Specifies a direction bit that ProtocolPak sets for all
requests originating from the local station. Options are:
– 0 = Used when operating in slave mode
– 1 = Used when operating in master mode
Since ProtocolPak only supports operations as a DNP slave (at present), this
parameter should not be modified from its default.
Default = 0
• IPROP_DNP_DATALINK_ADDRESS: This parameter is currently unused by
ProtocolPak and need not be modified.
Default = 0
• IPROP_DNP_DATALINK_TIMEOUT: Specifies the number of milliseconds
ProtocolPak waits for the remote station confirmation of a data link message before
re-sending it.
The setting of this parameter is only relevant if data link confirmation is enabled via
the parameter IPROP_DNP_DATALINK_CONFIRM.
Default = 4000
• IPROP_DNP_DATALINK_RETRY: Specifies the number of times ProtocolPak
re-sends an unconfirmed data link message before taking a degraded timeout.
The setting of this parameter is only relevant if data link confirmation is enabled via
the parameter IPROP_DNP_DATALINK_CONFIRM.

Note: DNP slaves in a frequently polled environment should not use data link
retries.
Default = 0
• IPROP_DNP_DATALINK_CONFIRM: Specifies the conditions under which
ProtocolPak requests remote station confirmation of a data link message.
– 0x00 = Never
– 0x01 = Always
– 0x08 = If message consists of multiple fragments, confirm all but last fragment
Note: Most implementations do not require data link confirmation (it is an

unnecessary overhead). In situations where the communications line is unreliable,
this can be required. However, application-layer confirmation is generally sufficient.
Default = 0 (0x00)
• IPROP_DNP_DATALINK_NAK: Specifies whether or not data link negative
acknowledgements can be sent to the remote station. Options are:
– 0 = Data link NAKs cannot be sent
– 1 = Data link NAKs can be sent
In most circumstances, this parameter should not be modified from its default value.
Default = 1
• IPROP_DNP_RESYNC_INTERVAL: Specifies the interval that DNP time
resynchronization is requested via the “Need Time” internal indications bit (in
seconds).
On startup, the “Need Time” IIN bit is set (to indicate to the remote station that time
synchronization is required). The “Need Time” IIN bit is subsequently reset when a
“Write Date and Time” operation is performed by the remote station.
If IPROP_DNP_RESYNC_INTERVAL is set to 0, the “Need Time” IIN bit is never set
again after the first time synchronization. However, if
IPROP_DNP_RESYNC_INTERVAL is greater than 0, this defines the length of time
(in seconds) after a “Write Date and Time” operation before the “Need Time” IIN bit
is once again set (to indicate to the remote station that another time synchronization
is required).
Default = 3600 (1 hour)

• IPROP_DNP_TPDU_SIZE: Specifies the transport layer protocol data unit length for
packets transmitted by ProtocolPak to the remote station (in bytes). For the vast
majority of users, the default value of this parameter is acceptable and need not be
changed.
Only values less than or equal to 250 are acceptable.
Default = 250
• IPROP_DNP_APDU_SIZE: Specifies the application layer protocol data unit length
for packets received and transmitted by ProtocolPak (in bytes). For the vast majority
of users, the default value of this parameter is acceptable and need not be changed.
Only values greater than or equal to 249 are acceptable.
Default = 2048
• IPROP_DNP_UNSOLICITED_TIMEOUT: Specifies the time that ProtocolPak waits
for the remote station to confirm an unsolicited message before re-sending it (in
milliseconds). The setting of this parameter is only relevant if unsolicited mode is
enabled (via the parameter IPROP_DNP_UNSOLICITED_MODE).
from its default.
Default = 5000
• IPROP_DNP_PARTIAL_RESULTS: For the vast majority of users, the default value
of this parameter is acceptable and need not be changed.
Default = 0
• IPROP_DNP_OBJECT_COUNT: Specifies the number of object definitions in the
ProtocolPak DNP object array. This parameter is read-only and it cannot be
modified.
Default = 82
• IPROP_DNP_SINGLE_FRAGMENT: Specifies whether ProtocolPak generates
multi-fragment application responses to remote station requests. Options are:
– 0 = Multi-fragment responses can be returned.
– 1 = Only single-fragment responses can be returned.
The most common reason to set this parameter to 1 is when the remote station does
not support the reception of multi-fragment application layer responses.
Default = 0
• IPROP_DNP_PERSISTENT_PATTERN: Used with the DNP “Pattern Control Block”
object (Object 12 Variation 2). Options are:
– 0
– 1
Default = 0

• IPROP_DNP_FILE_NAME_SIZE: Specifies the maximum file name length for
storage objects.
DNP file objects are presently unsupported, so this parameter should not be
modified from its default.
Default = 128
• IPROP_DNP_TEST_LINK: Specifies the maximum amount of time the transmission
line can remain idle when operating in unsolicited mode (in milliseconds). If the link
is idle for more than IPROP_DNP_TEST_LINK milliseconds, ProtocolPak issues a
Test Link data link request to verify the integrity of the link.
If this parameter is set to 0, this functionality is disabled.
Default = 1000
• IPROP_DNP_TEST_FUNCTION: Specifies whether ProtocolPak is to issue a Test
Link request or a Link Status request when operating in master mode. Options are:
– 2 = Issue Test Link
– Any other value = Issue Link Status
ProtocolPak does not presently support operations in master mode. Therefore, this
parameter need not be modified.
Default = 0
• IPROP_DNP_COLD_START_DELAY: Specifies the delay reported to the remote
station in the response to a cold restart request (in milliseconds).
This period indicates the expected time it will take for the local station (xx2smp) to
stop and restart in response to the cold restart request. Ideally, after requesting a
cold restart, the remote station waits for this period of time before attempting to
restart communications.
The default value (20 seconds) is generally more than long enough for xx2smp to
shut down (and be restarted by Process Starter).
Note: The “-x” xx2smp command-line argument must be provided, in order to have
the xx2smp application actually terminate after the reception of a cold restart
request from the remote station.
Default = 20000
• IPROP_DNP_REFRESH_RETRANSMIT: Specifies whether ProtocolPak is to
re-build the application frame when the primary station requests re-transmission.
Options are:
– 0 = Frame is not rebuilt.
– 1 = Frame is rebuilt.

The default setting ensures that ProtocolPak rebuilds the application frame when
re-transmitting it to the primary station. For the vast majority of users, this is the
desired behavior.
If this parameter is set to 0, an exact copy of the previously transmitted frame is
sent.
Default = 1
• IPROP_DNP_MAXIMUM_RELAYS: Specifies the maximum number of relay
controls that can be sent in a single request. A setting of zero indicates that the
maximum should be the number of controls that fit in a single request.
Default = 0
• IPROP_DNP_MAXIMUM_ANALOG_OUTPUTS: Specifies the maximum number of
analog output controls that can be sent in a single request. A setting of zero
indicates that the maximum should be the number of controls that fit in a single
request.
Default = 0
9.7.4.2 IEC101/104 Parameters

Table 15 can be used as a quick reference for the available IEC parameters. Detailed
descriptions of these parameters are given following the table.
Table 15. IEC Parameters Quick Reference

Parameter Default
IPROP_IEC_BALANCED_MODE 0
IPROP_IEC_COMMON_ADDRESS_SIZE 2
IPROP_IEC_OBJECT_ADDRESS_SIZE 2
IPROP_IEC_CONNECTION_TIMER 10000
IPROP_IEC_TRANSMISSION_FREQUENCY 1000
IPROP_IEC_SYSTEM_QUEUE 1
IPROP_IEC_CAUSE_SIZE 1
IPROP_IEC_ASDU_SIZE 255
IPROP_IEC_CLASS_1_CAUSE 3
IPROP_IEC_CLASS_2_CAUSE 2
IPROP_IEC_BALANCED_CLASS_1_CAUSE 3
IPROP_IEC_BALANCED_CLASS_2_CAUSE 2
IPROP_IEC_ASDU_CONFIRM 2
IPROP_IEC_DATALINK_CONFIRM 1
IPROP_IEC_DATALINK_TIMEOUT 2000

Parameter Default
IPROP_IEC_DATALINK_RETRY 3
IPROP_IEC_TIME_ADJUSTMENT 1
IPROP_IEC_ACTIVATION_BLOCKS 2
IPROP_IEC_DATALINK_ADDRESS_SIZE 1
IPROP_IEC_DATALINK_ADDRESS 1
IPROP_IEC_SHORT_DATA_LINK_ACK 0
IPROP_IEC_SHORT_DATA_LINK_NAK 0
IPROP_IEC_OBJECT_COUNT 128
IPROP_IEC_STARTUP 0
IPROP_IEC_RESYNC_INTERVAL 3600000
IPROP_IEC_TIME_WINDOW 3600000
IPROP_IEC_DIRECTION 0
IPROP_IEC_DATALINK_DEGRADED_TIMEOUT 10000
IPROP_IEC_PEER_TO_PEER 0
IPROP_IEC_ACCESS_DEMAND 1
IPROP_IEC_FULL_TIMESTAMP 1
IPROP_IEC_TEST_LINK 0
IPROP_IEC_FILE_COUNT 2
IPROP_IEC_END_OF_DIRECTORY 0
IPROP_IEC_CHANGE_DETECT 0
IPROP_IEC_COMPATIBILITY 247
IPROP_IEC_EVENT_CLASS 0
IPROP_IEC_DATALINK_TYPE 0
IPROP_IEC_104_T0_CONNECT_TIMEOUT 30
IPROP_IEC_104_T1_SEND_TIMEOUT 15
IPROP_IEC_104_T2_NO_DATA_TIMEOUT 10
IPROP_IEC_104_T3_TEST_TIMEOUT 30
IPROP_IEC_104_K_SIZE 12
IPROP_IEC_104_W_SIZE 8
IPROP_IEC_POLL_FREQUENCY 500
IPROP_IEC_POLL_TIMEOUT 4000
IPROP_IEC_POLL_RETRY 0
IPROP_IEC_SYNC_AFTER_DISCONNECT 0
IPROP_IEC_BI_DIRECTIONAL 0

Parameter Default
IPROP_IEC_CONFORMANCE 2
IPROP_IEC_OBJECTS *
* = See description later in this section.
For the IEC101 and IEC104 protocols, the following parameters can be configured in
the protocol data set:
• IPROP_IEC_BALANCED_MODE: Specifies whether or not ProtocolPak should use
balanced mode transmission once the device has been initialized. Options are:
– 0 = Balanced mode disabled
– 1 = Balanced mode enabled
If balanced mode is selected, the parameter IPROP_IEC_DIRECTION should be set
appropriately.
Default = 0
• IPROP_IEC_COMMON_ADDRESS_SIZE: Specifies the size of the IEC common
address in bytes. Options are:
– 1
– 2
Default = 2
• IPROP_IEC_OBJECT_ADDRESS_SIZE: Specifies the size of the IEC object
information address in bytes. Options are:
– 1
– 2
– 3
Default = 2
• IPROP_IEC_CONNECTION_TIMER: Specifies the connection timer value in
milliseconds. This parameter is currently unused by ProtocolPak and need not be
modified.
Default = 10000
• IPROP_IEC_TRANSMISSION_FREQUENCY: Specifies the base transmission
frequency for Class 2 data in milliseconds. This is a multiplier for the cycle frequency
specified in the IEC objects array (configurable via the IPROP_IEC_OBJECTS
parameter).
For example, if the cycle frequency for the single point information object in the IEC
objects array is 5 (seconds) and IPROP_IEC_TRANSMISSION_FREQUENCY

is 2000 (milliseconds), the single point information object is returned in response to
background scan polls every 10 seconds.
If IPROP_IEC_TRANSMISSION_FREQUENCY is 0, ProtocolPak does not transmit
Class 2 data in response to background scans. In such a case, ProtocolPak
continues to transmit Class 1 events and respond to device interrogations, but no
periodic transmission of Class 2 data occurs.
Default = 1000
• IPROP_IEC_SYSTEM_QUEUE: Specifies the manner in which ProtocolPak is to
store events, either in a single event queue (per device) or in multiple queues (per
object). Options are:
– 0 = Maintain separate event queues for each object.
– 1 = Maintain a single event queue for all objects.
ProtocolPak does not support separate per-object event queues; therefore, this
parameter must never be set to 0.
Note that there is nothing to gain by using separate event queues per object.
The size of the single event queue (used for all objects) can be modified via the
IPROP_EVENT_QUEUE_LENGTH parameter in the CFE data set.
Default = 1
• IPROP_IEC_CAUSE_SIZE: Specifies the size of the cause of transmission in bytes.
Options are:
– 1
– 2
Default = 1
• IPROP_IEC_ASDU_SIZE: Specifies the maximum size of the data link frame for
ASDUs in bytes.
Default = 255
• IPROP_IEC_CLASS_1_CAUSE: Specifies the Cause-of-Transmission field in the
ASDU when the local station sent the ASDU in response to an unbalanced Class 1
poll from the remote station. Options are:
– 1 = Periodic, cyclic
– 2 = Background scan
– 3 = Spontaneous
– 4 = Initialized
– 5 = Request or requested
– 6 = Activation
– 7 = Activation confirmation

– 8 = Deactivation
– 9 = Deactivation confirmation
– 10 = Activation termination
– 11 = Return information caused by a remote command
– 12 = Return information caused by a local command
– 13 = File transfer
– 14–19 = Reserved
– 20 = Interrogated by general interrogation
– 21 = Interrogated by group 1 interrogation
– 37 = Requested by general counter request
– 38 = Requested by group 1 counter request
– 42–47 = Reserved
– 48–63 = Special use (private range)

Default = 3
• IPROP_IEC_CLASS_2_CAUSE: Specifies the Cause-of-Transmission field in the
ASDU when the local station sent the ASDU in response to an unbalanced Class 2
poll from the remote station. Options are the same as given for
IPROP_IEC_CLASS_1_CAUSE.
Default = 2
• IPROP_IEC_BALANCED_CLASS_1_CAUSE: Specifies the
Cause-of-Transmission field in the ASDU when the local station sent the ASDU in
balanced mode because there were events to report (Class 1 transmission). Options
are the same as given for IPROP_IEC_CLASS_1_CAUSE.
Default = 3
• IPROP_IEC_BALANCED_CLASS_2_CAUSE: Specifies the
Cause-of-Transmission field in the ASDU when the local station sends static data
(Class 2 transmission) in balanced mode. Options are the same as given for
IPROP_IEC_CLASS_1_CAUSE.
Default = 2
• IPROP_IEC_ASDU_CONFIRM: Specifies whether optional ASDU confirmations are
enabled or disabled.
– 0x01 = Enables confirmation of reset process ASDUs
– 0x02 = Enables confirmation of ASDUs with the test flag set
Default = 3 (0x03)
• IPROP_IEC_DATALINK_CONFIRM: Specifies whether ProtocolPak uses data link
confirmation for balanced mode transmissions. Options are:
– 0 = Do not use data link confirmation.
– 1 = Use data link confirmation.
Default = 1
• IPROP_IEC_DATALINK_TIMEOUT: Specifies the timeout for data link
acknowledgements in milliseconds. If an acknowledgement is not received in this
interval, the originating request fails.
Default = 2000
• IPROP_IEC_DATALINK_RETRY: Specifies the number of times to retry a
confirmed data link transmission in balanced mode before declaring a failure (when
an acknowledgement is not received).
Default = 3

• IPROP_IEC_TIME_ADJUSTMENT: Specifies whether or not ProtocolPak performs
an adjustment on the time it receives from the remote station before writing the clock
(upon reception of a clock synchronization command). Options are:
– - 0 = ProtocolPak performs the time adjustment using the remote station
timestamp and the message arrival timestamp.
– - 1 = ProtocolPak performs the time adjustment using the message arrival
timestamp.
If this parameter is set to 0, no time adjustment is performed. If IEC104 is selected
(by setting the parameter IPROP_IEC_DATALINK_TYPE to 1),
IPROP_IEC_TIME_ADJUSTMENT must be set to 0. Otherwise, time
synchronizations do not work correctly. Indeed, this setting is enforced in
ProtocolPak.
However, note that, when IEC101 is selected, the user can set this parameter to
either 0 or 1.
Default = 1 (IEC 101)
Default = 0 (IEC 104 – mandatory setting that cannot be changed by the user)
• IPROP_IEC_ACTIVATION_BLOCKS: Specifies the number of activation blocks.
The value specified must be greater than or equal to 2.
Default = 2
• IPROP_IEC_DATALINK_ADDRESS_SIZE: Specifies the size of the data link
address in bytes. Options are:
– 0
– 1
– 2
Default = 1
• IPROP_IEC_DATALINK_ADDRESS: Specifies the data link address.
This parameter must be set to 0 if IEC104 is selected (via
IPROP_IEC_DATALINK_TYPE), since IEC104 does not use a data link address.
The range of values that can be supplied here is dependent on the setting of
IPROP_IEC_DATALINK_ADDRESS_SIZE.
Default = 1
• IPROP_IEC_SHORT_DATA_LINK_ACK: Specifies whether to enable or disable
the use of short data link acknowledgements. Options are:
– 0 = Disabled
– 1 = Enabled
Default = 0

• IPROP_IEC_SHORT_DATA_LINK_NAK: Specifies whether to enable or disable
the use of short data link negative acknowledgements. Options are:
– 0 = Disabled
– 1 = Enabled
Default = 0
• IPROP_IEC_OBJECT_COUNT: Specifies the number of object definitions in the
ProtocolPak IEC object array. This parameter is read-only and it cannot be modified.
Default = 128
• IPROP_IEC_STARTUP: Specifies the startup conditions that must be met before
the device becomes operational.
– 0x01 = Indicates that an “End of Initialization” APDU is added to the event queue
and sent to the remote station in the response to the first Class 1 request that is
received.
– 0x02 = Indicates that a General Interrogation request must be received from the
remote station before the local station responds to Class 1 and Class 2 requests.
– 0x04 = Indicates that a clock synchronization must be received from the remote
station before the local station responds to Class 1 data requests.
Default = 0 (0x00)
• IPROP_IEC_RESYNC_INTERVAL: Specifies the clock re-synchronization interval
in milliseconds. Event timestamps are valid from the time the remote station syncs
the clock to the clock-sync time plus IPROP_IEC_RESYNC_INTERVAL.
ProtocolPak flags timestamps as invalid for events that occur after the
re-synchronization interval and before the next clock sync.
If this parameter is set to 0, ProtocolPak does not flag any timestamps as invalid.
• IPROP_IEC_TIME_WINDOW: Specifies the clock synchronization window in
milliseconds.
• IPROP_IEC_DIRECTION: Specifies the value of the direction bit in ProtocolPak
transmissions. The direction bit is the upper bit of the control octet used in balanced
mode transmissions. Options are:
– 0 = Data from controlled to controlling station
– 1 = Data from controlling to controlled station
Default = 0

• IPROP_IEC_DATALINK_DEGRADED_TIMEOUT: Specifies the number of
milliseconds ProtocolPak delays between retry cycles when seeking confirmation of
a data link message.
Default = 10000
• IPROP_IEC_PEER_TO_PEER: Specifies whether peer-to-peer communications
should be used. Options are:
– 0 = Normal operations
– 1 = Peer-to-peer operations
The value set for this parameter must match that set for
IPROP_IEC_BI_DIRECTIONAL.
ProtocolPak does not presently support master mode operations (which is a
prerequisite for peer-to-peer operations). Therefore, this parameter should not be
Default = 0
• IPROP_IEC_ACCESS_DEMAND: Specifies the response that should be returned to
the remote station upon reception of an Access Demand request. Options are:
– 0 = Send a link service not implemented response
– 1 = Send a status of link response
Default = 1
• IPROP_IEC_FULL_TIMESTAMP: Specifies whether ProtocolPak is to use the
CP56Time2a or the CP24Time2a time format when reporting timestamps. Options
are:
– 0 = Use the CP24Time2a format.
– 1 = Use the CP56Time2a format.
Default = 1
• IPROP_IEC_TEST_LINK: Specifies the maximum amount of time (in milliseconds)
the transmission line can remain idle when operating in balanced mode. If the link is
idle for more than IPROP_IEC_TEST_LINK milliseconds, ProtocolPak issues a Test
Link data link request to verify the integrity of the link.
If this parameter is set to 0, this functionality is disabled.
Default = 0
• IPROP_IEC_FILE_COUNT: Specifies the number of files that can be opened
concurrently by ProtocolPak. If set to 1, concurrent file transfers between the remote
and local station are inhibited. Values greater than 1 allow more than one file
transfer to take place at any one time.
ProtocolPak does not presently provide support for IEC file objects. Therefore, this
parameter need not be modified.

Default = 2
• IPROP_IEC_END_OF_DIRECTORY: Specifies whether RES1 status should be set
in A_DIRECTORY_req. Options are:
– 0 = RES1 is not set.
– 1 = RES1 is set.
ProtocolPak does not presently provide support for IEC file objects. Therefore, this
parameter need not be modified from its default.
Default = 0
• IPROP_IEC_CHANGE_DETECT: This parameter need not be modified from its
default.
Default = 0
• IPROP_IEC_COMPATIBILITY: Specifies compatibility modes.
– 0x01 = IEC_COMPATIBILITY_DEVICE_EVENTS
Unused
– 0x02 = IEC_COMPATIBILITY_CANCEL_INTERROGATION
= 0 : First interrogation is interrupted and cancelled if a second one occurs before
activation termination.
= 1 : If a second interrogation occurs while the first one is processing, the second
one is processed after the first one.
– 0x04 = IEC_COMPATIBILITY_CLOCK_SYNC_ACTTERM
= 0 : Slave responds only with activation confirmation.
= 1 : Slave responds with activation confirmation and activation termination.
– 0x08 = IEC_COMPATIBILITY_ON_HOUR
= 0 : The clock synchronization window is to be used (defined by
IPROP_IEC_TIME_WINDOW).
= 1 : No clock synchronization window.
– 0x10 = IEC_COMPATIBILITY_FREEZE_TERMINATION
Unused
– 0x20 = IEC_COMPATIBILITY_CANCEL_CLOCK_SYNC
= 0 : Clock synchro aborts current interrogation.
= 1 : Clock synchro does not abort current interrogation.

The default is to set all compatibility modes apart from
IEC_COMPATIBILITY_ON_HOUR. The default is equivalent to
(0xFF & ~IEC_COMPATIBILITY_ON_HOUR).
Most users should not need to modify this parameter from its default value.
Default = 247 (0xF7)
• IPROP_IEC_EVENT_CLASS: Specifies whether ProtocolPak is to process Class 2
data in the same manner in which Class 1 data is processed (via event queues).
If this parameter is set to 1, ProtocolPak maintains two separate event queues: one
queue is for Class 1 events, while the second queue contains Class 2 changes.
ProtocolPak ignores the transmission frequency property
(IPROP_IEC_TRANSMISSION_FREQUENCY), which is ordinarily used to transmit
data to the remote station in the background. Instead, ProtocolPak streams all
Class 2 changes to the remote station in queue order — i.e., the Class 2 stream is a
time-ordered stream of variable changes. Options are:
– 0 = Class 2 event queuing is not supported.
– 1 = Class 2 event queuing is supported.
Class 2 event queuing is presently unsupported. Therefore, this parameter should
not be modified from its default.
Default = 0
• IPROP_IEC_DATALINK_TYPE: Specifies whether IEC101 or IEC104 is to be used.
Options are:
– 0 = IEC101 (IEC_DATALINK_FT_1_2)
– 1 = IEC104 (IEC_DATALINK_104)
If IEC104 is selected, the following parameter settings must also be made:
– IPROP_COMMSTYPE = NETWORK
– IOC_PORT = 2404
– IPROP_IEC_DATALINK_ADDRESS = 0
– IPROP_IEC_TIME_ADJUSTMENT = 0
Default = 0 (IEC101)
• IPROP_IEC_104_T0_CONNECT_TIMEOUT: Specifies the number of seconds that
ProtocolPak waits for a connection to be established before declaring a timeout.
The setting of this parameter is only relevant when IEC104 has been selected (via
IPROP_IEC_DATALINK_TYPE).
Default = 30
• IPROP_IEC_104_T1_SEND_TIMEOUT: Specifies the number of seconds that
ProtocolPak waits for an acknowledgement of the last transmitted data frame.

Default = 15
• IPROP_IEC_104_T2_NO_DATA_TIMEOUT: Specifies the number of seconds that
ProtocolPak waits for an I-frame before sending an S-frame (waits for a new data
frame before acknowledging the last received data frame).
Default = 10
• IPROP_IEC_104_T3_TEST_TIMEOUT: Specifies the number of seconds the link
must remain idle before a Test Link frame is sent — i.e., the frequency ProtocolPak
sends Test Link frames when the connection is idle.
Default = 30
• IPROP_IEC_104_K_SIZE: Specifies the maximum number of I-format ASDUs (data
frames) that can be transmitted before an acknowledgment must be received from
the remote station. The connection is closed if an acknowledgement is not received
in IPROP_IEC_104_T2_NO_DATA_TIMEOUT seconds.
Default = 12
• IPROP_IEC_104_W_SIZE: Specifies the number of unacknowledged I-format
APDUs the local station receives before transmitting an acknowledgement.
Default = 8
• IPROP_IEC_POLL_FREQUENCY: Specifies the frequency that ProtocolPak checks
for changes when operating in balanced mode (in milliseconds).
This parameter is also used when operating in master mode. However, ProtocolPak
does not currently support operations in master mode.
Default = 500
• IPROP_IEC_POLL_TIMEOUT: Specifies the timeout applied to poll requests
generated at the poll frequency (in milliseconds).
This parameter is only used when operating in master mode. However, since
ProtocolPak does not currently support operations in master mode, there is no need
to modify this parameter.
Default = 4000

• IPROP_IEC_POLL_RETRY: Specifies the number of times ProtocolPak retries a
request that has not responded in the poll timeout interval when operating in
balanced mode.
This parameter is also used when operating in master mode. However, ProtocolPak
does not currently support operations in master mode.
Default = 0
• IPROP_IEC_SYNC_AFTER_DISCONNECT: Specifies whether ProtocolPak should
re-synchronize with the controlling station after detecting a link disconnect when the
IEC104 data link frame format is in use. Options are:
– 0 = Do not re-synchronize.
– 1 = Re-synchronize.
Default = 0
• IPROP_IEC_BI_DIRECTIONAL: Specifies whether ProtocolPak is to allow for
bi-directional transmissions between the local station and the remote station.
Options are:
– 0 = Bi-directional transmissions are not allowed.
– 1 = Bi-directional transmissions are allowed.
The value set for this parameter must match that set for
IPROP_IEC_PEER_TO_PEER.
If IPROP_IEC_DATALINK_TYPE is set to 1 (IEC104 is in use) and if
IPROP_IEC_BI_DIRECTIONAL is set to 1, ProtocolPak supports bi-directional
transmissions with the remote station.
ProtocolPak does not presently support master mode operations (which is a
prerequisite for bi-directional transmissions). Therefore, this parameter should not be
Default = 0
• IPROP_IEC_CONFORMANCE: Specifies whether ProtocolPak is to enforce strict
conformance to IEC revisions.
– 0x00 = No conformance enforced
– 0x02 = Strict conformance to IEC Revision A
Currently, the only supported conformance option is for IEC Revision A. When this
property is set to 0x02, ProtocolPak:
– Echoes the TSC and time for all received Test ASDUs with time

– Actively terminates a 104 connection after the remote station has confirmed a
Reset Process ASDU
– Does not set the day-of-week in an ASDU that transmits the date/time
Default = 2 (0x02)
• IPROP_IEC_OBJECTS: This parameter allows for the customization of the IEC
objects array maintained in ProtocolPak. This array contains a number of elements.
Each element corresponds to a specific IEC object, and the values associated with
each element allow for the customization of the behavior of that object.
By default, the IEC objects array is configured with values that are adequate in most
situations. If the defaults are acceptable, there is no need to customize the array.
However, if the defaults are not acceptable, there is a mechanism to customize a
particular element of the array. In order to customize an element of the array, the
data set parameter and value strings must be provided in the following format:
IPROP_IEC_OBJECTS[XXX]=A:B:C
where the left side of the equals sign represents the data set parameter and the right
side represents the data set value.
An array syntax is used to represent the element that is to be modified. In practice,
the numeric IEC object identifier is supplied in place of XXX — e.g., to customize the
IEC double-point object, replace XXX with “3”.
If multiple elements are to be customized (i.e., for multiple objects), this parameter
can be supplied multiple times. In such a case, each instance should supply the
requisite object identifier substituted for XXX.
The data set value (A:B:C) represents the members of the IEC objects array that the
user can customize (for the corresponding IEC object with the object identifier XXX).
The members are as follows:
– “A” defines the class of the data. It is implemented as a bit mask. If multiple flags
are required, the requisite flags should be bitwise ORed together. The flags that
can be set are as follows:
∗ 0x00 = IEC_CLASS_DEMAND – Object is only delivered when requested.
∗ 0x01 = IEC_CLASS_1 – Object is delivered on a Class 1 scan.
∗ 0x02 = IEC_CLASS_2 – Object is delivered on a Class 2 scan.
∗ 0x04 = IEC_CLASS_GENERAL – Object is supplied on general interrogation.
∗ 0x08 = IEC_CLASS_COUNTER – Object is supplied on counter interrogation.
∗ 0x10 = IEC_CLASS_CONTROL – Control outputs.

– “B” defines the activation class of the object. The activation class determines
when ProtocolPak reports ASDU activation, confirmation, and completion events
to the remote station. These events can be reported in response to Class 1
requests, Class 2 requests, or both Class 1 and Class 2 requests. Options are:
∗ 0 = No class
∗ 1 = Class 1
∗ 2 = Class 2
∗ 3 = Class 1 and Class 2
For example, objects with an activation class of 3 have confirmation events, etc.
sent in response to either Class 1 or Class 2 polls from the remote station. This
ensures that the remote station receives the message as quickly as possible
(which is important for control termination messages, etc.).
– “C” defines the cycle frequency for the return of Class 2 data in response to
background scans (in seconds). “C” is a multiplier that is applied to the user-
specified base frequency (IPROP_IEC_TRANSMISSION_FREQUENCY). The
result determines the frequency Class 2 data is returned for this particular object
in response to background scans.
The base transmission frequency is set to 1000 (milliseconds) by default. In such
a case, the value supplied through “C” is the cycle frequency (in seconds) that is
used for this object. “C” can be set to 0 to disable the reporting of Class 2 data
for this object in response to background scans.
As with all numeric ProtocolPak parameters, each of these values must be supplied in
decimal (XXX, A, B, C).
Note: The colons separating the three values (A:B:C) are required. No other character
can be substituted.
If you are customizing an element of the array and you want to accept the default value
for A, B, or C, the character “X” can be provided in place of an actual value. For
example, if you want to modify the double-point information object so that the cycle
frequency is set to 20, yet you are happy with the default settings for both the class and
activation class, you should provide the data set parameter:
IPROP_IEC_OBJECTS[3]=X:X:20
Table 16 shows the default configuration of the IEC objects array. All values in the table
are in decimal. The Object ID column corresponds to the value for XXX that is required
to customize an element of the array. The Class column corresponds to “A”, the
Activation Class column corresponds to “B”, and the Cycle Frequency column
corresponds to “C”.
Note that the Cycle Frequency is set to 0 for all objects by default. This means that, by
default, you do not perform cyclic (background) transmission of any objects. If cyclic
transmission is required, you must set the Cycle Frequency to some non-zero value for
the requisite object.

Table 16. ProtocolPak IEC Object Array Defaults
Object ID Class Activation Class Cycle Frequency
1 6 2 0
2 1 1 0
3 6 2 0
4 1 1 0
5 6 2 0
6 1 1 0
7 6 2 0
8 1 1 0
9 6 2 0
10 1 1 0
11 6 2 0
12 1 1 0
13 6 2 0
14 1 1 0
15 10 2 0
16 1 1 0
17 1 1 0
18 1 1 0
19 1 1 0
20 4 1 0
21 6 2 0
45 16 3 0
46 16 3 0
47 16 3 0
48 16 3 0
49 16 3 0
50 16 3 0
51 16 3 0
58 16 3 0
59 16 3 0
60 16 3 0
61 16 3 0
62 16 3 0
63 16 3 0

Object ID Class Activation Class Cycle Frequency
64 16 3 0
70 0 3 0
100 0 3 0
101 0 3 0
102 0 3 0
103 0 1 0
104 0 3 0
105 0 3 0
106 0 3 0
107 0 3 0
110 0 3 0
111 0 3 0
112 0 3 0
113 0 3 0
120 0 3 0
121 0 3 0
122 0 3 0
123 0 3 0
124 0 3 0
125 0 3 0
126 0 3 0
9.7.4.3 Telegyr 8979 Parameters

Table 17 can be used as a quick reference for the available Telegyr 8979 parameters.
Detailed descriptions of these parameters are given following the table.
Table 17. Telegyr 8979 Parameters Quick Reference

Parameter Default
IPROP_GYR_FIRMWARE_CONFIGURATION 1
IPROP_GYR_SELECT_TIMER 1
IPROP_GYR_AUTO_CONFIGURE 1
IPROP_GYR_BACKGROUND_FREQUENCY 1000
IPROP_GYR_CARD_CODES N/A
IPROP_GYR_CARD_SIZES N/A

Parameter Default
IPROP_GYR_TIME_ADJUSTMENT 1
For the Telegyr 8979 protocol, the following parameters can be configured in the
protocol data set:
• IPROP_GYR_FIRMWARE_CONFIGURATION: Specifies the firmware revision
number as a decimal integer. This number is reported in response to a “Firmware
Configuration” request from the master (function code 39).
Default = 1
• IPROP_GYR_SELECT_TIMER: Specifies a conversion factor applied to the timer
count specified in select commands.
The “SBO Select” Telegyr command (function code 21) includes a “Timer Count”,
which is used as a multiplier in order to determine how long to activate the selected
point. The time interval per count is preset in the RTU (xx2smp/ProtocolPak). The
time interval per count is represented by the parameter
IPROP_GYR_SELECT_TIMER.
The “Timer Count” received from the master (in a select command) is multiplied by
the value of IPROP_GYR_SELECT_TIMER in order to produce a millisecond
timeout. This timeout is used to determine how long to activate the selected point.
However, although this value is calculated, it is not passed to the e-terracontrol
database, since it is generally irrelevant with the standard configurations of xx2smp
and e-terracontrol. Therefore, the value of this parameter need never be modified
from its default.
Default = 1
• IPROP_GYR_AUTO_CONFIGURE: Specifies whether ProtocolPak should
automatically compute the chassis number and slot number for all variables. Options
are:
– 0 = ProtocolPak reads the value of some special internal configuration variables
in order to get the user-assigned chassis and slot numbers for each variable.
This option is not supported and should not be selected.
– 1 = ProtocolPak uses the Telegyr 8979 card type to index into the
IPROP_GYR_CARD_CODES and IPROP_GYR_CARD_SIZES arrays, in order
to compute the chassis number and slot number for each variable.
– Table 17 shows the default card codes and card sizes as configured via the
parameters IPROP_GYR_CARD_CODES and IPROP_GYR_CARD_SIZES,
respectively.
Default = 1

Table 18. Telegyr 8979 Card Codes and Card Sizes
Telegyr 8979 Card Type Card Code Card Size
(variables per card)
No Slot 0 N/A
Analog Input 1 8
Analog Reference 2 8
Analog Output 3 8
Indication Input 4 16
24-bit Digital Output 5 24
SBO Control Output 7 16
Digital Input 8 16
Pulse Input 12 8
Pulse Output 15 8
SOE Input 28 16
ProtocolPak maps the card types to Telegyr 8979 data types (objects). Then, starting
with chassis 0, slot 0, ProtocolPak assigns chassis and slot numbers to all defined
variables. ProtocolPak does this according to the order of the card types listed above. It
first determines the total number of analog input variables. It then divides the number of
variables by the card size to determine the number of slots that the variables require. If
the number of slots exceeds 15, ProtocolPak increments the chassis number (as
appropriate). ProtocolPak processes the other variable data types in the same way.
Note: Not all master stations use chassis and slot numbers (Landis and Gyr stations
do). If the master station does not use chassis and slot numbers, leaving the default
setting of IPROP_GYR_AUTO_CONFIGURE (1) is sufficient. However, auto
configuration may not work for master stations that use chassis and slot numbers. In
such a case, it might be necessary to set IPROP_GYR_AUTO_CONFIGURE to 0. At
present, this option is not supported; if this is causing difficulties for your installation,
contact Alstom Grid.
• IPROP_GYR_BACKGROUND_FREQUENCY: Specifies the frequency (in

milliseconds) that ProtocolPak performs background analog input processing. All
analog inputs are polled in the background at this frequency. If set to 0, then no
background polling is performed. Deadbands are only processed when analog data
is requested.
Default = 1000
• IPROP_GYR_CARD_CODES: Specifies an array of codes corresponding to the
Telegyr 8979 card types. This array is used to compute chassis numbers and slot
numbers. The default settings in this array are specified in the second column of

Table 18. At present, this parameter is not exposed, and the entries in the array
cannot be modified from their defaults.
• IPROP_GYR_CARD_SIZES: Specifies an array containing the number of variables
per card for each Telegyr 8979 card type. This array is used to compute chassis
numbers and slot numbers. The default settings in this array are specified in the third
column of Table 18. At present, this parameter is not exposed, and the entries in the
array cannot be modified from their defaults.
• IPROP_GYR_TIME_ADJUSTMENT: Specifies whether time bias is applied to clock
sync requests. Options are:
– 0 = No
– 1 = Yes
Default = 1
9.7.5 RTU Data Set

An example of a typical RTU data set (of type RtuDS) is shown in Figure 28. No data
items need to be supplied in this data set.
Figure 28. RTU Data Set Example

• IPROP_LOCAL_ADDRESS: Specifies the address of the local station — i.e., the
address that is to be used by ProtocolPak. Different protocols make different uses of
this parameter, as follows:
– DNP: IPROP_LOCAL_ADDRESS represents the address of the local station.
– IEC101/104: IPROP_LOCAL_ADDRESS represents the common address
(station address). Note that, for IEC, the parameter

IPROP_IEC_DATALINK_ADDRESS (in the protocol data set) must also be set in
order to fully specify the local station addressing information (note that, for
IEC104, the data link address is not used and
IPROP_IEC_DATALINK_ADDRESS must be set to 0).
– GYR: IPROP_LOCAL_ADDRESS represents the RTU address.
Default = 1
• IPROP_REMOTE_ADDRESS: Specifies the address of the remote station (master
station). Different protocols make different uses of this parameter, as follows:
– DNP: IPROP_REMOTE_ADDRESS represents the address of the remote
(master) station.
– IEC101/104: IPROP_REMOTE_ADDRESS is not used and need not be set.
– GYR: IPROP_REMOTE_ADDRESS is not used and need not be set.
Default = 1
• IPROP_STRICT_REMOTE_ADDRESSING: Specifies whether or not strict remote
addressing is to occur. Options are:
– 0 = Not strict
– 1 = Strict
If remote addressing is not strict, responses are sent to requests originating from
any remote address (note that this makes the setting of
IPROP_REMOTE_ADDRESS moot). If remote addressing is strict, only requests
originating from the remote station with an address corresponding to
IPROP_REMOTE_ADDRESS are serviced.
The default setting (0) allows for the fact that certain ProtocolPak slaves may not
know beforehand the address of the remote station that is communicating with them.
At present, this parameter is used only for the DNP protocol. It need not be modified
for IEC101/104 or GYR.
Default = 0

9.7.6 ScanGroup Data Set
An example of a typical ScanGroup data set (of type ScanGroupDS) is shown in Figure
29. No data items need to be supplied in this data set.
Figure 29. ScanGroup Data Set Example

• LINKDATATYPE: Specifies the numeric protocol-specific object identifier for this
scan group. The options for LINKDATATYPE differ depending on the protocol that is
in use:
– For DNP, the options are as follows:
∗ 1 = DNP_BINARY_INPUT
∗ 12 = DNP_RELAY_CONTROL
∗ 20 = DNP_COUNTER_INPUT
∗ 21 = DNP_FROZEN_COUNTER_INPUT **
∗ 30 = DNP_ANALOG_INPUT
∗ 31 = DNP_FROZEN_ANALOG_INPUT **
∗ 41 = DNP_ANALOG_OUTPUT
∗ 70 = DNP_FILE **
∗ 81 = DNP_STORAGE_OBJECT **
∗ 82 = DNP_DEVICE_DATA **
Note that, for DNP, the number of objects instantiated for types 10 and 40 is
automatically set to be the same as the number of objects instantiated for
types 12 and 41, respectively. For this reason, objects 10 and 40 are not valid

LINKDATATYPEs (for an exact description of the supported DNP object types,
variations, functions, and qualifiers, refer to the ProtocolPak DNP device profile
in section 9.14.1 DNP Device Profile).
– For IEC101 and IEC104, the options are as follows:
∗ 1 = IEC_SINGLE_INPUT
∗ 3 = IEC_DOUBLE_INPUT
∗ 5 = IEC_STEP_POSITION
∗ 7 = IEC_BINARY_STRING
∗ 9 = IEC_ANALOG_NORMALIZED
∗ 11 = IEC_ANALOG_INPUT
∗ 13 = IEC_ANALOG_FLOAT
∗ 15 = IEC_FROZEN_COUNTER
∗ 17 = IEC_PROTECTION_EVENT **
∗ 18 = IEC_START_EVENT **
∗ 19 = IEC_OUTPUT_CIRCUIT **
∗ 20 = IEC_PACKED_SINGLE_WITH_CHANGE
∗ 45 = IEC_SINGLE_COMMAND
∗ 46 = IEC_DOUBLE_COMMAND
∗ 47 = IEC_REGULATING_STEP_COMMAND
∗ 48 = IEC_ANALOG_OUTPUT_NORMALIZED
∗ 49 = IEC_ANALOG_OUTPUT_SCALED
∗ 50 = IEC_ANALOG_OUTPUT_FLOAT
∗ 51 = IEC_BINARY_OUTPUT_STRING
∗ 110 = IEC_PARAMETER_NORMALIZED
∗ 111 = IEC_PARAMETER_SCALED
∗ 112 = IEC_PARAMETER_FLOAT
∗ 120 = IEC_FILES **
– For Telegyr 8979 (GYR), the options are as follows:
∗ 1 = GYR_ANALOG_INPUT
∗ 5 = GYR_ANALOG_REFERENCE
∗ 7 = GYR_INDICATION
∗ 9 = GYR_SOE

∗ 11 = GYR_DIGITAL_INPUT
∗ 12 = GYR_ACCUMULATOR
∗ 13 = GYR_FROZEN_ACCUMULATOR **
∗ 20 = GYR_ANALOG_OUTPUT
∗ 21 = GYR_SBO
∗ 23 = GYR_DIGITAL_OUTPUT
∗ 25 = GYR_PULSE_OUTPUT
Note: Objects denoted with “**” are not currently supported. However, support may
be provided for these objects in the future.
The LINKDATATYPE parameter does not have a default and must be provided.
• IPROP_OBJECT_CLASS: Specifies the object class assignment on a per-variable
basis. This parameter is optional and is generally not required for most installations.
Each protocol supported by ProtocolPak uses a default set of class assignments.
These assignments are as follows:
– For DNP, all variables for all objects (that support events) are assigned to
Class 1.
– For IEC, the default class assignments are described in Table 16 (with the
description of the parameter IPROP_IEC_OBJECTS).
– For GYR, class assignment is unused and the parameter
IPROP_OBJECT_CLASS need never be provided.
For DNP, if the default class assignment (Class 1) is not acceptable, the
IPROP_OBJECT_CLASS parameter can be used to set the required class
assignments on a per-variable basis.
For IEC, if the default class assignments are not acceptable, the
IPROP_IEC_OBJECTS parameter can be used to set the required class
assignments on a per-object basis.
Note: The IPROP_OBJECT_CLASS parameter is not supported for IEC and must
never be provided when IEC is in use.
The following dependencies related to this parameter must be noted:

– If this parameter is supplied and IPROP_PROTOCOL is set to DNP, the
parameter IPROP_DNP_EVENT_CLASS must be set to 1.
– If DNP unsolicited mode has been enabled (via the
IPROP_DNP_UNSOLICITED_MODE parameter), the parameter
IPROP_DNP_EVENT_CLASS must be set to 1. In addition, the appropriate
variables must be flagged for inclusion in unsolicited transmissions via the
IPROP_OBJECT_CLASS parameter (for further discussion of how this

parameter relates to the IPROP_OBJECT_CLASS parameter, refer to the
descriptions of the parameter IPROP_DNP_EVENT_CLASS).
The IPROP_OBJECT_CLASS parameter is supplied in the following format:
IPROP_OBJECT_CLASS=A:B:C
where the left side of the equals sign is the data set parameter and the right side is
the data set value.
The data set value (A:B:C) represents:
– The range of variable indexes for which the class is to be modified
– The class assignment that is to be applied
The object to which this assignment is to apply is implicitly presumed to be the same
object specified by the LINKDATATYPE parameter in the ScanGroup data set in
which the IPROP_OBJECT_CLASS parameter is supplied.
The values A:B:C represent the following:
– “A” defines the start index for the range of variables whose class is to be
modified.
– “B” defines the end index for the range of variables whose class is to be modified
(note that the start and end indexes can be the same if the class of just a single
variable is to be modified).
– “C” defines the class that is to be assigned to the object. The classes differ
depending on the protocol that is in use.
For DNP, the options for “C” are as follows:
∗ 0 = Variable is assigned to the static class. This disables event generation for
the variable.
∗ 1 = Variable is assigned to Class 1.
∗ 9 = Variable is assigned to Class 1 and is included in unsolicited mode
responses.
responses.
responses.
As with all numeric ProtocolPak parameters, the values for A, B, and C must be
supplied in decimal.
Note: The colons separating the three values (A:B:C) are required. No other
character can be substituted.

If you want to set different classes for the variables of a specific object, the
IPROP_OBJECT_CLASS parameter should be supplied multiple times in the
ScanGroup data set for that object.
For example, consider a configuration using DNP with 100 binary inputs (with
indexes 0 to 99). In this case, the ScanGroup data set has LINKDATATYPE=1.
In this data set, the following parameters can also be supplied:
IPROP_OBJECT_CLASS=0:20:1
In this example:
– Binary inputs with indexes 0 to 20 (inclusive) are assigned to Class 1.
– Binary inputs with indexes 81 to 85 (inclusive) have event generation disabled. If
an event is reported by the SCADA database for this variable, the event is not
passed to the remote station.
– Binary inputs with indexes 86 to 99 (inclusive) are assigned to Class 1. Note that
class allocations were not explicitly assigned for these variables. In such a case,
the default class allocation is used (for DNP, this is Class 1).
You can assign the entire range of variables for a specific object to a certain class by
specifying the start and end indexes so that they cover the entire index range for the
object.
Note that it does not make sense to supply the IPROP_OBJECT_CLASS parameter
in data sets whose LINKDATATYPEs are set as follows:
– For DNP, if LINKDATATYPE is:
∗ 12 (USER_DNP_RELAY_CONTROL)
∗ 41 (USER_DNP_ANALOG_OUTPUT)
∗ 70 (USER_DNP_FILE)
∗ 81 (USER_DNP_STORAGE_OBJECT)
∗ 82 (USER_DNP_DEVICE_DATA)
• IPROP_TIMESTAMP_EVENTS: Specifies whether timestamps are to be sent with
events on a per-variable basis or on a per–scan group basis.
This parameter can be used with all protocols. The behavior that results from the
use of this parameter differs depending on the protocol that is in use. However, the
end result is always the same — i.e., the respective events are sent without
timestamps. For example, if event timestamping is disabled for IEC analog
normalized variables, send these events using ASDU 9 (measured value,

normalized value) instead of ASDU 10 (measured value, normalized value with time
tag) or ASDU 34 (measured value, normalized value with time tag CP56Time2a).
Note that the default behavior is to timestamp all events — i.e., if this parameter is
not provided, events are always timestamped.
The IPROP_TIMESTAMP_EVENTS parameter can be provided in one of two
formats:
IPROP_TIMESTAMP_EVENTS=A:B:C
IPROP_TIMESTAMP_EVENTS=C
where the left side of the equals sign is the data set parameter and the right side is
the data set value. The data set value (either A:B:C or C) represents:
– The range of variable indexes for which the timestamp assignment is to be
modified.
– The timestamp assignment that is to be applied.
The object to which this assignment is to apply is implicitly presumed to be the same
object specified by the LINKDATATYPE parameter in the ScanGroup data set in
which the IPROP_TIMESTAMP_EVENTS parameter is supplied.
The values A, B, and C represent the following:
– “A” defines the start index for the range of variables whose timestamp
assignment is to be modified.
– “B” defines the end index for the range of variables whose timestamp assignment
is to be modified (note that the start and end indexes can be the same if only a
single variables timestamp assignment is to be modified).
– “C” defines whether a timestamp is to be associated with events for the variables
in the variable range specified by A and B. The options for “C” are either “Y” if
timestamps are to be sent with events or “N” if timestamps are not to be sent with
events.
If all three parameters are used (A:B:C), the timestamp handling assignment
(according to the value of C) is applied only to those parameters whose indexes fall
in the range A to B (inclusive). If only the parameter C is provided, the timestamp
handling assignment is applied to all variables in the ScanGroup in which the
IPROP_TIMESTAMP_EVENTS parameter is provided.
If you want to set different timestamp assignments for different variable ranges for a
specific object type, the IPROP_TIMESTAMP_EVENTS parameter can be supplied
multiple times in the ScanGroup data set for that object.
For example, consider a configuration using IEC with 100 single-point inputs (with
indexes 0 to 99). In this case, the ScanGroup data set has LINKDATATYPE=1. In
this data set, the following parameters can also be supplied:
IPROP_TIMESTAMP_EVENTS=21:40:N
IPROP_TIMESTAMP_EVENTS=81:85:N

In this example, all events for single inputs with indexes 21 to 40 (inclusive) and 81
to 85 (inclusive) are sent without timestamps. Events for all other indexes in that
ScanGroup are sent with timestamps (the default behavior).
You can apply the timestamp association for all of the variables in a ScanGroup by
supplying the IPROP_TIMESTAMP_EVENTS parameter as either:
IPROP_TIMESTAMP_EVENTS=Y
IPROP_TIMESTAMP_EVENTS=N
The first case is redundant since this is the default behavior. However, the second
case (setting the value to “N”) disables the transmission of timestamps with events
for all variables in the ScanGroup in which the IPROP_TIMESTAMP_EVENTS
parameter is provided.
As with all numeric ProtocolPak parameters, the values for A and B must be
supplied in decimal. Note that, if the values A, B, and C are provided, the colons
separating the three values are required. No other character can be substituted.
9.7.7 Card Data Set

An example of a typical card data set (of type CardDS) is shown in Figure 30. This data
set must include the requisite data items for the desired configuration.
The First and Count fields are used to set the indexes that are used. Multiple card data
sets can be created in a single ScanGroup data set, in order to configure
non-contiguous index ranges. However, in such a case, the union of data item indexes
of the card data sets must be unique. The data item index is equivalent to the protocol-
specific index that is used for each item.
Figure 30. Card Data Set Example

In this data set, the parameters listed below can be configured. The SMPDATATYPE
parameter does not have a default and must be provided. All other parameters are
optional.
• SMPDATATYPE: Specifies the data type that is to be used for all data items in this
data set. The options fall into six basic categories, as follows (note that these are not
the options that can be provided):
– Status: Maps to the SMP “Status” measurement type
– Analog: Maps to the SMP “Analog” measurement type
– Counter: Maps to the SMP “Accumulator” measurement type
– Control: Maps to the SMP “Control” type
– Setpoint: Maps to the SMP “Setpoint” type
– Limit: Maps to the SMP “Limit” type
The options that can be supplied are given below.
The basic types (without the RAW or RAW2 extension) work with engineering
values, either extracted from or written to the SCADA database.
The extended types (with a RAW or RAW2 extension) are used to define the manner
in which xx2smp extracts data from SCADA or sends data to SCADA. These types
use the scaling properties defined in the SCADA database, in order to determine the
value that is to be passed to the remote station or into SCADA itself.
The selection made for SMPDATATYPE is restricted according to the selection that
has been made for LINKDATATYPE in the enclosing ScanGroup data set (the
restrictions are discussed in section 9.7.7.1 Object Mapping Restrictions).
Options are:
– STATUS = Status Raw values. Normally transferred from xx2smp to the remote
station, but can also be transferred in the opposite direction.
– STATUSENG = Status Engineering values. Normally transferred from xx2smp to
the remote station, but can also be transferred in the opposite direction.
xx2smp retrieves the status Raw and Engineering values from SCADA. Status
Raw values are sent to SCADA by the device applications, like CFEReader, after
performing the protocol conversions. Normally, the status Raw and Engineering
values are the same; they differ only if the device application data item model
contains a conversion. xx2smp applies a protocol conversion on the status
measurement value if it is a double point and the protocol is IEC101 or IEC104.
The following data-flow diagram shows how the status point values are handled
in xx2smp.

– ANALOG = Analog (engineering value). xx2smp retrieves the engineering value
from SCADA and passes it to the remote station as such. Normally transferred
from xx2smp to the remote station, but can also be transferred in the opposite
direction.

– ANALOGRAW = Analog (raw value). xx2smp retrieves the plantside-written raw
value from SCADA and passes it to the remote station as such. Normally
transferred from xx2smp to the remote station, but can also be transferred in the
opposite direction.
– ANALOGRAW2 = Analog (calculated raw value). xx2smp retrieves the
engineering units value from SCADA, and back-calculates a raw value using the
scaling attributes from the SCADA data item. This back-calculated raw value
(rather than the actual raw value stored in the SCADA database) is then passed
to the remote station. Normally transferred from xx2smp to the remote station,
but can also be transferred in the opposite direction.
– COUNTER = Counter (engineering value). xx2smp retrieves the engineering
value from SCADA and passes it to the remote station as such. Transferred from
xx2smp to the remote station only.
– COUNTERRAW = Counter (raw value). xx2smp retrieves the plantside-written
raw value from SCADA and passes it to the remote station as such. Transferred
from xx2smp to the remote station only.
– COUNTERRAW2 = Counter (calculated raw value). xx2smp retrieves the
engineering units value from SCADA, and back-calculates a raw value using the
scaling attributes from the SCADA data item. This back-calculated raw value
(rather than the actual raw value stored in the SCADA database) is then passed
to the remote station. Transferred from xx2smp to the remote station only.
– CONTROL = Control. Used for controls from the remote station to SCADA.
– SETPOINT = Setpoint (engineering value). Used for setpoints from the remote
station to SCADA. The value received in the setpoint command is written to
SCADA as the engineering units value.
– SETPOINTRAW = Setpoint (raw value). Used for setpoints from the remote
station to SCADA. xx2smp inverse scales the setpoint value using the scaling
attributes from the SCADA data item in order to calculate a value in engineering
units. This value in engineering units is then written to SCADA. The received raw
value is subtracted from 65536 if it is greater than 32767.
– SETPOINTRAW2 = Setpoint (raw value). Used for setpoints from the remote
units. This value in engineering units is then written to SCADA. The received raw
value is subtracted from 65536 if it is greater than 32767.
– SETPOINTRAW3 = Setpoint (raw value). Used for setpoints from the remote
units. This value in engineering units is then written to SCADA.

– LIMIT = Limit (engineering value). Used for limits sent from the remote station to
SCADA. The value received in the limit command is written to SCADA as the
engineering units value.
– LIMITRAW = Limit (raw value). Used for limits sent from the remote station to
SCADA. xx2smp inverse scales the limit value using the scaling attributes from
the SCADA data item in order to calculate a value in engineering units. This
value in engineering units is then written to SCADA.
– LIMITRAW2 = Limit (calculated raw value). Used for limits sent from the remote
station to SCADA.
• DPCONVERSION: Specifies whether xx2smp should convert the double-point
status measurements from engineering to raw value. This is used only in IEC101
and IEC104 protocols.
– YES = value is converted to raw
– NO = no conversion is applied
Default=NO
• STEP: Specifies the amount to increment the object index as you go from one data
item to the next in the data set. In the vast majority of cases, the default value (1) is
acceptable.
Default = 1
• FIELDTIME: Specifies whether or not the device timestamp is passed to the remote
– 0 = SCADA timestamp passed
– 1 = Device timestamp passed
A value of 1 indicates that the device timestamp (as written into e-terracontrol) is
sent to the remote station. If you require device timestamps to be passed through
e-terracontrol and on to the remote station, this parameter must be set to 1.
A value of 0 indicates that the e-terracontrol timestamp is passed to the remote
station — i.e., the timestamp that e-terracontrol applied upon reception of a point is
sent to the remote station.
Default = 1
• TIMEOUT: For measurements written to e-terracontrol, specifies the number of
seconds before the output values are set to the data quality of OLD if they have not
been refreshed during this period. When set to 0, the timeout functionality is
disabled.
This parameter is related to the “-o” xx2smp command-line argument. Namely, any
setting made with the “-o” xx2smp command-line argument is taken as the default
for this value. If a value for the TIMEOUT parameter is provided, it overrides the “-o”
setting for all items in this card data set.

Default = 0 or value of “-o” command-line argument (if provided).
• EXECUTEON: Specifies how the mapped data item gets executed and allows the
mapping of a single CONTROL object to two separate controls. The setting of this
parameter is only relevant for card data sets where the SMPDATATYPE parameter
is set to CONTROL. Options are:
– 0 = Whenever the remote station sends a control with the value 0, it is executed.
– 4 = Whenever the remote station sends a control, it is executed (regardless of
the value passed with the control).
Default = 4
The EXECUTEON option provides the means to implement unipolar or bipolar
controls. A unipolar control means that only a single control operation can be
performed for any particular index — e.g., you can perform a trip on index 0 and a
close on index 1, but you cannot perform both a trip and a close on index 0. This
functionality is the default.
A bipolar control means that both trip and close operations can be performed on a
single index. For example, both a trip and a close can be performed on index 0.
Unipolar control functionality is enabled by default. If you want to enable bipolar
control functionality, you need to create multiple card data sets and set the
EXECUTEON parameter accordingly in each. Separate card data sets must be
created for trip and close controls. Each data set must contain the respective trip or
close data items linked to the respective controls. Depending on the protocol in use,
the data set for trip controls may have EXECUTEON=1 and the data set for close
controls may have EXECUTEON=0.
An example of a typical data set hierarchy is:
Controls (ScanGroupDS)
TripControls (CardDS) (First=0;Count=1;EXECUTEON=1)
DI:0 (linked to Station1 Unit1 STS1 Trip)
CloseControls (CardDS) (First=0;Count=1;EXECUTEON=0)
DI:0 (linked to Station1 Unit1 STS1 Close)
This example shows only a single data item in each data set. Of course, multiple
data items can be included.
Note: The trip data set must contain only trip controls, and the close data set must
contain only close controls.
In this case, upon receipt of a control for index 0 (say, DNP object 12 index 0) from
the master, xx2smp locates the relevant index in both cards. Subsequently, xx2smp

issues the control to the SCADA database that corresponds to the value sent (i.e.,
Trip if 1 is sent, Close if 0 is sent).
For IEC double commands, you generally set EXECUTEON=1 in the CardDS for
your “Open” (OFF) controls and EXECUTEON=2 in the CardDS for your “Close”
(ON) controls. Similar considerations apply for IEC regulating step commands.
• EVENTS: Specifies whether events are to be created for the data items in this card
data set. Options are:
– 0 = Events are not created for the data items in this card data set.
– 1 = Events are created for the data items in this card data set.
This parameter should be used whenever you do not want to create events for the
data items in a card data set.
Example 1: Many systems using IEC only require events to be created (and
inserted into Class 1) for a few high-priority points. In the default configuration, you
create events for all data items. This can lead to too many unimportant events being
sent to the remote station. Through the use of the EVENTS parameter, you can
disable event generation for those points where it is not required (by setting the
EVENTS parameter to 0 in the relevant card data sets).
Note: This necessitates the judicious creation of card data sets so that they
include only those points for which you do not require events. Points for which you
do require events must be included in a separate card data set with the EVENTS
parameter set to 1 or not supplied at all (since the default is 1).
Example 2: For IEC, normally integrated totals (counters) need only be reported to
the remote station upon a request from the remote station or at the background
cycle frequency. However, the default behavior (with EVENTS set to 1) is for all
counter changes to be transmitted in Class 1. This behavior can be modified by
setting the EVENTS parameter to 0 in the card data set(s) containing integrated
totals. The appropriate “cycle frequency” can then be set via the
IPROP_IEC_OBJECTS parameter. Most users probably want to follow these
instructions for integrated totals (although it is by no means mandatory).
Default = 1
9.7.7.1 Object Mapping Restrictions

Each protocol-specific object handled by xx2smp (whose type is specified via the
LINKDATATYPE parameter in the ScanGroup data set) must map to an object in the
SCADA database. The SCADA database has a limited set of object types as follows:
• Status
• Analog
• Accumulator

• Control
• Setpoint
• Limit
The SMPDATATYPE parameter in the card data set specifies the mapping to use.
However, the selection that can be made for SMPDATATYPE is limited based on the
selection that has been made for LINKDATATYPE. The valid options are presented in
the tables below.
The measurements linked in the data items of the card data set must be of the
appropriate e-terracontrol type according to the restrictions outlined below.
Table 19. DNP Object Mapping Restrictions

DNP “LINKDATATYPE” Selection Valid “SMPDATATYPE” Selection(s)
1 (DNP_BINARY_INPUT) STATUS
12 (DNP_RELAY_CONTROL) CONTROL
20 (DNP_COUNTER_INPUT) COUNTER
COUNTERRAW
COUNTERRAW2
21 (DNP_FROZEN_COUNTER_INPUT) ** COUNTER
COUNTERRAW
COUNTERRAW2
30 (DNP_ANALOG_INPUT) ANALOG
ANALOGRAW
ANALOGRAW2
31 (DNP_FROZEN_ANALOG_INPUT) ** ANALOG
ANALOGRAW
ANALOGRAW2
41 (DNP_ANALOG_OUTPUT) SETPOINT
SETPOINTRAW
SETPOINTRAW2
SETPOINTRAW3
70 (DNP_FILE) ** Not Supported
81 (DNP_STORAGE_OBJECT) ** Not Supported
82 (DNP_DEVICE_DATA) ** Not Supported
Table 20. IEC Object Mapping Restrictions

IEC “LINKDATATYPE” Selection Valid “SMPDATATYPE” Selection(s)
1 (IEC_SINGLE_INPUT) STATUS
3 (IEC_DOUBLE_INPUT) STATUS

IEC “LINKDATATYPE” Selection Valid “SMPDATATYPE” Selection(s)
5 (IEC_STEP_POSITION) ANALOG
ANALOGRAW
ANALOGRAW2
7 (IEC_BINARY_STRING) STATUS
9 (IEC_ANALOG_NORMALIZED) ANALOG
ANALOGRAW
ANALOGRAW2
11 (IEC_ANALOG_INPUT) ANALOG
ANALOGRAW
ANALOGRAW2
13 (IEC_ANALOG_FLOAT) ANALOG
15 (IEC_FROZEN_COUNTER) Not Supported
COUNTERRAW
COUNTERRAW2
17 (IEC_PROTECTION_EVENT) ** Not Supported
18 (IEC_START_EVENT) ** Not Supported
19 (IEC_OUTPUT_CIRCUIT) ** Not Supported
20 (IEC_PACKED_SINGLE_WITH_CHANGE) ANALOG
ANALOGRAW
ANALOGRAW2
45 (IEC_SINGLE_COMMAND) CONTROL
46 (IEC_DOUBLE_COMMAND) CONTROL
47 (IEC_REGULATING_STEP_COMMAND) CONTROL
48 (IEC_ANALOG_OUTPUT_NORMALIZED) SETPOINT
SETPOINTRAW
49 (IEC_ANALOG_OUTPUT_SCALED) SETPOINT
SETPOINTRAW
50 (IEC_ANALOG_OUTPUT_FLOAT) SETPOINT
SETPOINTRAW
51 (IEC_BINARY_OUTPUT_STRING) CONTROL
110 (IEC_PARAMETER_NORMALIZED) SETPOINT
SETPOINTRAW
111 (IEC_PARAMETER_SCALED) SETPOINT
SETPOINTRAW
112 (IEC_PARAMETER_FLOAT) SETPOINT
120 (IEC_FILES) ** Not Supported

Table 21. Telegyr 8979 Object Mapping Restrictions
GYR “LINKDATATYPE” Selection Valid “SMPDATATYPE” Selection(s)
1 (GYR_ANALOG_INPUT) ANALOG
ANALOGRAW
ANALOGRAW2
5 (GYR_ANALOG_REFERENCE) ANALOG
ANALOGRAW
ANALOGRAW2
7 (GYR_INDICATION) STATUS
9 (GYR_SOE) STATUS
11 (GYR_DIGITAL_INPUT) STATUS
12 (GYR_ACCUMULATOR) COUNTER
COUNTERRAW
COUNTERRAW2
13 (GYR_FROZEN_ACCUMULATOR) ** Not Supported
20 (GYR_ANALOG_OUTPUT) SETPOINT
SETPOINTRAW
21 (GYR_SBO) CONTROL
23 (GYR_DIGITAL_OUTPUT) CONTROL
25 (GYR_PULSE_OUTPUT) CONTROL
Note: Objects denoted with “**” are not currently supported. However, support can be
provided for these objects in the future.
9.7.7.2 IEC Object Support Notes

IEC floating-point objects (13, 112) must have their SMPDATATYPE set to ANALOG
(not ANALOGRAW or ANALOGRAW2). This is because you do not want any scaling to
occur on these points; you simply want the engineering value to be used as it stands by
xx2smp. For these objects, the value communicated into or out of the SCADA database
is expected to be in floating-point format and is passed as such.
IEC object 20 (packed single with change) is supported. However, it is up to the user to
ensure that the associated measurement is configured with the appropriate value to be
sent to the remote station. This may necessitate the use of a calculation to retrieve the
values from multiple status points and copy them into the analog that is used by
object 20.
IEC bitstring objects: The CfeReader application has the capacity to be configured to
read a bitstring ASDU and split it up to be written into 32 separate status points.
However, xx2smp does not possess the inverse functionality — i.e., xx2smp cannot be

configured to read 32 separate statuses and report them as a single bitstring ASDU.
Instead, when configuring xx2smp, the bitstring object is mapped to a single status
point, and it is up to the user to configure the value stored in this status point
appropriately — i.e., the user must manually configure the 32-bit string through a
calculation.
9.7.7.3 Data Items

Data item objects belong to the card data set and are linked to measurement and
control objects. They correspond to the physical connections in the RTUs, PLCs, and
Intelligent Electronic Devices (IEDs). Data item parameters include point name, point
index, raw low/high, engineering low/high, deadband, scale, and measurement/control
linkages (for column descriptions, refer to “Data Items Tab for Data Set” in the
Note: For the Bit field, selecting “SInv” for a given data item inverts the bit prior to
transmission to the master. Selecting anything other than “SInv” instructs the xx2smp
application not to invert the bit prior to transmission to the master. This only applies to
Status and Control objects.
9.7.8 PseudoCard Data Set

An example of a typical PseudoCard data set (of type PseudoCardDS) is shown in
Figure 31. No data items need to be supplied in this data set.
Figure 31. PseudoCard Data Set Example

The PseudoCard data set appears at the same point in the data set hierarchy as the
card data set. It is currently used only in conjunction with secure network
communications, and it serves to allow data set state pseudopoints from the security
data set’s alarm child to be transmitted to the remote station as points.
Each of the parameters configurable in the card data set can also be configured in the
PseudoCard data set. In addition, the following parameters must be configured:
• ADDRESS[X]: Specifies the PseudoCard data item address and protocol-specific
address as “ADDRESS[X]=N”, where:
– X = PseudoCard’s data item index (typically 0-based)
– N = Data item’s protocol-specific address/index
• PSEUDOPOINT[X]: Specifies the data set hierarchy of the pseudo-point as
“PSEUDOPOINT[X] =“A B C D E F””, where:
– X = PseudoCard’s data item index (typically 0-based)
– A = Cfereader data set name
– B = Cfe data set name
– C = Security data set name
– D = Security alarm data set name
– E = Security alarm status data set name
– F = Security alarm status data set state measurement name
Note: The double quotation marks around the value string (A B C D E F) are required
(for more information about the configuration of this data set, refer to the ProtocolPak
Security Configuration User’s Guide).

9.7.9 Security Data Set
An example of a typical security data set (of type SecurityDS) is shown in Figure 32. No
data items need to be supplied in this data set.
Caution: This data set must be named “Security” (case-sensitive).
Figure 32. Security Data Set Example
The security data set is used to configure parameters that are used when secure
communications have been selected (through the IPROP_COMMSTYPE parameter in
the CFE data set). The security data set need only be created if secure communications
have been enabled.
• SSL_TOKEN_SUPPORT: Specifies whether token support is to be enabled.
Options are:
– 0 = Token support disabled (using soft certificates)
– 1 = Token support enabled
Default = 0
• SSL_RENEGOTIATION_INTERVAL: Specifies the frequency that server-triggered
SSL renegotiations are to occur (in minutes). Options are:
– 0 = Server-triggered renegotiations are never performed.
– xxx: Server-triggered renegotiations are performed every xxx minutes.
Default = 1440 (24 hours)

• SSL_CRL_SUPPORT: Specifies whether ProtocolPak is to attempt to load a CRL
from disk. At present, the CRL is only loaded upon program startup (it is not
periodically reloaded thereafter). If a CRL is to be loaded, it must be present in a file
named “sslcrl.crl” in the working directory of the xx2smp application. Options are:
– 0 = Do not attempt to load a CRL upon startup.
– 1 = Attempt to load a CRL upon startup.
Default = 0
• SSL_CRL_RETRIEVAL_INTERVAL: Specifies the frequency that the CRL is
retrieved (via LDAP) from the remote server (in minutes).
At present, ProtocolPak does not support CRL retrieval. Therefore, this parameter
need not be modified from its default.
• SSL_TOKEN_EVENT_DETECTION_INTERVAL: Specifies the interval that the
token reader is polled for token insertion and removal events (in milliseconds).
In most circumstances, this parameter should not be modified from its default. It
should never be set to a value less than 250.
Default = 250
• SSL_LOCAL_IDENTITY_CERT_EXPIRATION_DETECTION_INTERVAL:
Specifies the frequency that the local identity certificate is checked to determine how
long before it expires. If the certificate expiration is pending (if there are less than
SSL_LOCAL_IDENTITY_CERT_EXPIRATION_NOTIFICATION_TIME minutes
before the certificate expires), the certificate expiration alarm is activated and the
associated database point is set.
• SSL_OTHER_CERT_EXPIRATION_DETECTION_INTERVAL: Specifies the
frequency that all other local certificates (apart from the local identity certificate) are
checked to determine how long before they expire (in minutes).
• SSL_AUTO_DELETE_EXPIRED_LOCAL_IDENTITY_CERT: Specifies whether the
local identity certificate should be automatically deleted from the token upon
expiration. Options are:
– 0 = No
– 1 = Yes
ProtocolPak does not presently support the automatic deletion of the local identity
certificate from the token. Therefore, this parameter need never be set to 1.
Default = 0

• SSL_LOCAL_IDENTITY_CERT_EXPIRATION_NOTIFICATION_TIME: When the
local identity certificate has this many (or fewer) minutes before expiration, the local
identity certificate expiration pending alarm is triggered.
Default = 86400 (60 days)
Further explanations of these parameters can be found in the ProtocolPak Security
Configuration User’s Guide.
The security data set may have a child data set. This serves as a root node for security
alarms statuses data sets.
9.7.10 Security Alarms Data Set

An example of a typical security alarms data set (of type SecurityDS) is shown in Figure
33. No data items need to be supplied in this data set.
Caution: This data set must be named “Alarms” (case-sensitive).
Figure 33. Security Alarms Data Set Example
The security alarms data set is of type SecurityDS. If this data set is supplied, the
security alarms statuses child data set should also be supplied. The security alarms
data set need only be created if secure communications have been enabled.
This data set is described in more detail in the ProtocolPak Security Configuration
User’s Guide.

9.7.11 Security Alarms Statuses Data Set
An example of a typical security alarms statuses data set (of type SecurityDS) is shown
in Figure 34. No data items need to be supplied in this data set.
Figure 34. Security Alarms Statuses Data Set Example
The security alarms statuses data set need only be created if secure communications
have been enabled.
• PSEUDOCARD: Specifies the data set hierarchy of the PseudoCard. The value is
set to A B C D E F, where:
– A = Cfereader data set name
– B = Cfe data set name
– C = Port data set name
– D = RTU alarm data set name
– E = ScanGroup data set name
– F = PseudoCard data set name
• DATAITEMNDX: Specifies the index in the list of data items in the PseudoCard data
set.
Further explanations of these parameters can be found in the ProtocolPak Security
Configuration User’s Guide.

9.7.12 xx2smp Status Data Set Tree
The xx2smp status data set tree is a separate data set tree from the measurement data
set tree, in that it is used to write communication status information to SCADA.exe
rather than to read values from SCADA.exe.
9.7.13 Root Status Data Set

An example of a typical root status data set (of type xx2smpDS_Status) is shown in
Figure 35.
Caution: This data set must have the same name as the xx2smp data set, with the
word “Status” (case-sensitive) appended to the end with a preceding underscore and
without a space.
Figure 35. Root Status Data Set Example

9.7.14 Status Data Set
An example of a typical status data set (of type StatusDS) is shown in Figure 36.
Caution: This data set must have the same name as the xx2smp master data set
(case-sensitive).
Figure 36. Status Data Set Example
The status data set is used as a means to store status information (pertaining to the
operation of the ProtocolPak control) in the SCADA database.
The status information that ProtocolPak communicates to xx2smp is made up of the
following values:
• Connected Status
• Error Count
• Bytes Tx
• Bytes Rx
The “Connected Status” indicator is an indication sent by ProtocolPak, denoting whether
a connection is currently established with the remote station. This indicator is discussed
in further detail in section 9.5 ProtocolPak Connection Status Indicator.
The “Error Count”, “Bytes Tx”, and “Bytes Rx” indicators represent the same information
as displayed in the diagnostics window. These indicators are described in section 9.2.2
Diagnostics Window.
The status data set provides the means whereby these indicators can be written to the
SCADA database. From there, they can be used for innumerable purposes — not the
least of which are for automated monitoring tasks or for presentation to operators.

Each of the four indicators is written into a separate data item. These data items must
be linked to measurements where the values are to be stored. The connected status
must be mapped to a Status measurement in the database. The other three indicators
must be mapped to Analog measurements. The four data items must be located in the
status data set at data item indexes 0 to 3.
The data items at indexes 0 to 3 must correspond to the following indicators:
• 0 = Connected Status
• 1 = Error Count
• 2 = Bytes Tx
• 3 = Bytes Rx
That is, the Connected Status indicator must always be located at data item index 0 in
the status data set. Similarly, the Bytes Tx indicator must always be located at data item
index 2 in the status data set, etc.
An example of the data items that should be present in a typical status data set is
shown in Figure 37.
Figure 37. Typical Status Data Set Data Items
Note that a “long” (i.e., long integer variable) is provided for the storage of the error
count and Bytes Tx/Bytes Rx indicators. To that end, the raw and engineering values for
these data items are set according to the maximum value that can be stored in a “long”.
Indeed, the corresponding analog measurements should also reflect these same limits.
If the remote station is deemed as disconnected, the connected indicator is 0. If the
remote station is deemed as connected, the connected indicator is 1.
Upon startup of the xx2smp application, each of the four data items is set to 0.

The status data set is not mandatory (i.e., the application still functions in its absence).
However, it is strongly recommended that the status data set be created, so that the
aforementioned system parameters can be viewed and monitored if so desired.
The “Error Count” is incremented under most circumstances in which ProtocolPak might
encounter a problem. However, there are conditions under which an error may occur
but the Error Count indicator cannot be incremented. To that end, even if the Error
Count indicator is 0, it does not guarantee that operations are ongoing without problems
(although it does provide a reasonable level of assurance that this is indeed the case).
Caution: In order for the data items in the status data set to be updated by xx2smp,
the data source used by xx2smp must have Write access to the xx2smp status data
set tree. If the data set has only Read access, xx2smp cannot update the data items in
the SCADA database.
9.7.15 Mapping Data Set States Through Data Items

It is possible to map data items configured for use by xx2smp to data set states. Note
that, ordinarily, all data items are mapped solely to measurements/controls.
This functionality can be useful where a data set state in the SCADA database needs to
be reported to a remote station via xx2smp. A prime example of this is where both
CFEReader and xx2smp are in use with SMP. In such cases, CFEReader is generally
communicating with RTUs, and xx2smp is generally communicating with a higher-level
station. In such circumstances, it can be beneficial to have the ability to communicate
the status of each RTU (managed by CFEReader) up to the higher-level station via
xx2smp. This requirement can be met by creating an xx2smp data item for each RTU
state and mapping these data items to the appropriate CFEReader RtuDS data set
states.
The assignment of a data item to a data set state cannot be made through the SCADA
GUI (Data Items tab), since this only allows the assignment of data items to
measurements/controls. Rather, the assignment can only be made through an import
file.
An example of an extract of an import file, including a data set for RTU states, is shown
below. Note that the “MeasNameStr” is mapped to a data set state (including the
“STAT” state measurement at the end). Also note that the CardDS is of type
ANALOGRAW2, and that the card should be defined under a scan group for analogs.
Begin DataSet RTU_Statuses
Type = CardDS
ParamStr = SMPDATATYPE=ANALOGRAW2
MaxErrors = 0
States = STA
States = STAA
States = STB
States = STAB
States = STAT

States = STT
DICount = 1
FirstDI = 0
Begin DataItem 0
DIName = 0
MeasNameStr = CFE_Reader CFE ComPort3 S30 STAT
RawLow = 0
RawHigh = 3
EngLow = 0
EngHigh = 3
Max = 0
Deadband = 0
ScanFilter = 0
Scale = 1
ConvTableIndex = 0
Negate = False
End
End
In order to implement this functionality, the xx2smp data model must include a CardDS
under the analogs scan group. This card should contain a number of data items, each of
which must be configured to point to the state measurement of the appropriate RtuDS
under the CFEReader data set.
Note that the mapping can be made to any data set state — i.e., the data items need
not map to a data set state in the xx2smp data set, nor need they map solely to an
RtuDS data set.
Note also that it is not necessary to modify the data sets configured in the xx2smp data
source as a result of the mapping performed herein. That is, just because you map to a
data set state outside of the xx2smp data set hierarchy, it does not mean that you need
to include access to this new data set in your xx2smp data source.
Note that such data items must be modeled as analogs.
The values reported through these data items (representing the data set states) are as
follows:
• 0 = offline
• 1 = unknown
• 2 = online
• 3 = failed
These values must be interpreted appropriately by the remote master station, in order to
determine the state of the mapped item.

9.8 Text File Configuration
The preferred means to configure xx2smp is through SCADA data sets. However,
another means whereby xx2smp can be configured is through a configuration file on
disk. This mechanism is selected with the “-t” command-line argument.
Use of the text file configuration mechanism is still supported, although strongly
deprecated. There are a number of reasons for the deprecation of this configuration
mechanism, including:
• Data sets provide an easier and more manageable/extensible means to configure
xx2smp.
• Advanced configuration mechanisms (IPROP and IOC parameters) are not exposed
through the configuration files.
• The ability to pass device timestamps to the remote master is not available in text
file configuration mode (only in data set configuration mode). The e-terracontrol
timestamp is always used in text file configuration mode.
There are a number of other drawbacks to using configuration files that are not
mentioned here.
If you are upgrading an old system that is currently using configuration files, it is strongly
recommended that you transfer the configurations contained in the files into data sets.
If the “-t” command-line argument is specified, xx2smp looks for a text file named
“xx2smp.txt” (in the current working directory) for its configuration information. If the “-f”
command-line argument is also specified, xx2smp looks for a file of the specified name.
Since the use of the text file configuration mechanism is deprecated, this document
does not contain further information about the means whereby text files can be
configured.
If you are adamant in your use of text files, refer to a previous release (e.g.,
e-terracontrol 3.2.2) containing the e-terracontrol Reference Manual (standalone
document) for instructions for text file configuration.
9.9 Measurement Mode Configuration

The preferred means to configure xx2smp is through the SCADA data sets. However,
another means whereby xx2smp can be configured is through the “measurement
mode”, which uses a configuration file on disk. This mechanism is selected with the “-m”
command-line argument.
Use of the measurement mode configuration mechanism is still supported, although
strongly deprecated.
The configuration information in the configuration file for the measurement mode is
supplied to xx2smp in a text file similar to that used in Text File configuration mode.
However, in this case, the <Begin Data> and <End Data> blocks are not used.

9.10 Sample Databases
The e-terracontrol installation installs a number of sample databases that can be used
with xx2smp. They are each installed in the \samples directory. It is generally wise to
use these databases as templates when configuring new systems.
The databases are as follows:
• xx2smp_DNP.sdb: Sample database for serial DNP communications
• xx2smp_IEC101.sdb: Sample database for IEC101 communications
• xx2smp_GYR.sdb: Sample database for Telegyr 8979 communications
• xx2smp_RIG.sdb: Sample database for token supported configurations (using
secure DNP over IP) (for more information about the security features of
ProtocolPak, refer to the ProtocolPak Security Configuration User’s Guide)
• xx2smp_DPG.sdb: Sample database for soft certificate supported configurations
(using secure DNP over IP) (for more information about the security features of
ProtocolPak, refer to the ProtocolPak Security Configuration User’s Guide)
9.11 Control Response Notifications

The SCADA application includes the means to communicate the actual result of a
control or setpoint operation back to the xx2smp application (some time after the control
or setpoint is performed). The xx2smp application makes use of this result in order to
generate the appropriate response to be sent back to the remote station. The response
indicates the status of the control/setpoint operation.
In the following description, note that the term “control” can be interchanged with the
term “setpoint” — i.e., the description applies equally to both controls and setpoints.
The control response functionality is most useful with the IEC protocol. However, a
subset of the functionality is also used with the other protocols supported by xx2smp.
The logic employed is as follows:
• A control is received from the remote station and sent to SCADA.
• Following the transmission of the control to SCADA, the xx2smp application blocks
for IPROP_CONTROL_RESPONSE_WAIT_PERIOD milliseconds.
– This time allows for the fact that SCADA may send back a control response very
shortly after receiving the control. This occurs if, for example, the control was
blocked by a tag.
– If a control response is received from SCADA in
IPROP_CONTROL_RESPONSE_WAIT_PERIOD milliseconds, the result code
in the synchronous response to the master station is set accordingly (depending
on whether SCADA indicates success or failure).

– For IEC, if a notification is received (in
IPROP_CONTROL_RESPONSE_WAIT_PERIOD milliseconds) and it indicates
that an error has occurred, an activation confirmation message is transmitted
with the P/N bit set to 1 (indicating an error). Conversely, if a notification
message is received and it indicates successful control completion, an activation
confirmation message is transmitted with the P/N bit set to 0.
– Finally, if no notification is received from SCADA in
IPROP_CONTROL_RESPONSE_WAIT_PERIOD milliseconds, presume
success and return the appropriate message to the remote station (for IEC, this
is an activation confirmation with the P/N bit set to 0).
• For protocols such as DNP 3, the logic terminates here — i.e., the synchronous
response sent shortly after reception of the control is all that the master ever
receives. The master station may subsequently perform additional steps to check
that the control has succeeded (e.g., verification of feedback measurements).
However, for protocols such as IEC, the situation is more complicated.
• For IEC, xx2smp may receive a control response notification at any time following
the execution of the control (before the control timeout period has expired). If this
notification indicates that the control has succeeded, an activation termination event
is created. Conversely, if this notification indicates that the control has failed, you do
not create an activation termination event.
Some miscellaneous points of note are as follows:
• For IEC, the reception of an activation termination event is used by the master to
determine whether a control has been operated successfully.
• It should be noted that the blocking wait performed by xx2smp following the
transmission of a control to SCADA (for
IPROP_CONTROL_RESPONSE_WAIT_PERIOD milliseconds) stops all
communication with the remote station for this period of time.
• For this reason, the value of the parameter
IPROP_CONTROL_RESPONSE_WAIT_PERIOD cannot be set to anything greater
than 300 (milliseconds). In general, if an error response is returned from SCADA
(soon after the transmission of a control), it is usually returned within 50 ms of the
transmission of the control request from xx2smp to SCADA.
It should be noted that, at any one time in xx2smp, this functionality only allows for a
single outstanding control and a single outstanding setpoint. In reality, this restriction is
imposed on a per-device basis. However, it is a moot point, since xx2smp presently only
supports a single device.
The theory behind this restriction is that it is generally unwise to have more than a
single control/setpoint selected in a remote station at any one time. Indeed, most IEC
implementations operate under this assumption.

Some of the associated restrictions are:
• While waiting for a SELECT/BREAK OFF/EXECUTE confirmation, no new
SELECT/BREAK OFF/EXECUTE command is sent. This rule is applicable per
controlled station.
• When a select and execute command (TI-45 or TI-46) has been given by the user
process, no new select and execute or direct command (except TI-47, TI-48, and TI-
51) is treated by the protocol until the ongoing select and execute command has
reached any of the following states:
– The SELECT command is completed and has been followed by an EXECUTE
command.
– A timeout between the command and the command confirmation has occurred in
any of the stages.
– A negative command confirmation has been received (P/N=1).
– The select and execute command has been deactivated (BREAK OFF command
given).
These rules are applicable per controlled station — the aim being to have only one
selected point in a controlled station at a time. However, regulating step commands,
setpoint commands, and bit string commands (TI-47, TI-48, and TI-51) are allowed in
between single and double commands.
9.12 Protocol-Specific e-terracontrol Quality Mapping

The e-terracontrol application maintains a 16-bit internal quality for each configured
measurement. This quality is appropriately mapped to the protocol-specific quality flags
used by each protocol supported by ProtocolPak.
The following sections discuss the mapping that is implemented in each of these cases.
Each protocol-specific object maps to a status, an analog, or an accumulator in the
SCADA database. The following sections categorize the quality mapping according to
the type of object in the SCADA database.
Importantly, the SCADA database only reports changes to the test mode quality flag if
the data source has Read access. If the data source used by xx2smp has Write access,
changes to the test mode indicator are not reported to xx2smp; therefore, those
changes cannot be reported to the remote station. Be aware that selecting Read access
disables other functionality (such as the status reporting to the database, as described
in section 9.7.12 xx2smp Status Data Set).

9.12.1 DNP Quality Mapping
The following sections detail the quality status mapping between e-terracontrol and
DNP.
Note that, in all of the following cases, if there is no active connection between SCADA
and the xx2smp application, the DNP “Online” bit is set to 0.
A “1” in the following tables indicates that the DNP quality bit is set to 1 if the
corresponding e-terracontrol quality bit is set. A “0” in the following tables indicates that
the DNP quality bit is set to 0 if the corresponding e-terracontrol quality bit is set.
9.12.1.1 Status Objects
Table 22. DNP Status Objects Quality Mapping

e-terracontrol Online Restart Comm Remote Local Chatter Reserved
Lost Force Force Filter
Unacknowledged
Abnormal
Old 1
Bad 0
Not-In-Service 0 1
Manual 1
Uninitialized 0
Inhibited
Tagged
LimitN
Limit1
Limit2
Limit3
Test 0
Commanded

9.12.1.2 Analog Objects
Table 23. DNP Analog Objects Quality Mapping

e-terracontrol Online Restart Comm Remote Local Over Ref. Reserved
Lost Force Force Range Check
Unacknowledged
Abnormal
Old 1
Bad 0
Not-In-Service 0 1
Manual 1
Uninitialized 0
Inhibited
Tagged
LimitN
Limit1
Limit2
Limit3
Test 0
Commanded
Over Range 1
9.12.1.3 Accumulator Objects
Table 24. DNP Accumulator Objects Quality Mapping

e-terracontrol Online Restart Comm Remote Local Rollover Reserved Reserved
Lost Force Force
Unacknowledged
Abnormal
Old 1
Bad 0
Not-In-Service 0 1
Manual 1
Uninitialized 0
Inhibited
Tagged

e-terracontrol Online Restart Comm Remote Local Rollover Reserved Reserved
Lost Force Force
LimitN
Limit1
Limit2
Limit3
Test 0
Commanded
The DNP “Rollover” bit is set if the value of the counter is

xi < xi-1.
9.12.2 IEC Quality Mapping

The following sections detail the quality status bit mapping between e-terracontrol and
IEC101/104.
Note that, in all of the following cases, if there is no active connection between SCADA
and the xx2smp application, the IEC IV bit is set to 1.
A “1” in the following tables indicates that the IEC bit is set if the corresponding
e-terracontrol bit is set.
Abbreviations are used for the IEC status bits. The abbreviations are as follows:
• BL: Blocked/Not Blocked
• SB: Substituted/Not Substituted
• NT: Not Topical/Topical
• IV: Invalid/Valid
• OV: Overflow/No Overflow
• CY: Carry (Counter Overflow)
• CA: Counter Adjustment
9.12.2.1 Status Objects
Table 25. IEC Status Objects Quality Mapping

e-terracontrol IV NT SB BL
Unacknowledged
Abnormal
Old 1
Bad 1

e-terracontrol IV NT SB BL
Not-In-Service 1 1
Manual 1
Uninitialized 1
Inhibited
Tagged
LimitN
Limit1
Limit2
Limit3
Test 1
Commanded
9.12.2.2 Analog Objects
Table 26. IEC Analog Objects Quality Mapping

e-terracontrol IV NT SB BL OV
Unacknowledged
Abnormal
Old 1
Bad 1
Not-In-Service 1 1
Manual 1
Uninitialized 1
Inhibited
Tagged
LimitN
Limit1
Limit2
Limit3
Test 1
Commanded
Over Range 1

9.12.2.3 Accumulator Objects
Table 27. IEC Accumulator Objects Quality Mapping

e-terracontrol IV CY CA
Unacknowledged
Abnormal
Old
Bad 1
Not-In-Service 1
Manual
Uninitialized 1
Inhibited
Tagged
LimitN
Limit1
Limit2
Limit3
Test 1
Commanded
The IEC CY bit is set if the value of the counter is xi < xi-1.
9.12.3 Telegyr 8979 Quality Mapping

The Telegyr 8979 protocol does not use any quality flags from the SCADA database.
Therefore, there are no quality mapping tables similar to those used with DNP and IEC.

9.13 Troubleshooting Network Data Transmission
Symptoms:
Data is sent by xx2smp but never received by the master. The frame is lost somewhere
between xx2smp and the master.
Fix:
In some cases, some long frames are not sent by the Windows TCP/IP layer or the
network board. It is as if one external component to xx2smp reaches a length limitation.
A register key allows you to set the maximum size of a frame. The key name is “MTU”
and it is located:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\
Interfaces]
Set the value of this key to a smaller value than the length causing the problem.
9.14 Interoperability Information
9.14.1 DNP Device Profile

This section provides detailed information about the exact support provided through
ProtocolPak for the DNP protocol. This information may be useful when determining
whether ProtocolPak is compatible with a particular master device.
The DNP User’s Group has certified ProtocolPak in accordance with DNP 3 Level 2.
The DNP device profile document submitted as part of this certification is shown in
Figure 38.

DNP 3.0
DEVICE PROFILE DOCUMENT
This document must be accompanied by a table having the following headings:
Object Group Request Function Codes Response Function Codes

Object Variation Request Qualifiers Response Qualifiers
Object Name (optional)
Vendor Name: Alstom Grid
Device Name: xx2smp V2.0.9
Highest DNP Level Supported: Device Function:
For Requests Level 2 Master Slave
For Responses Level 2
Notable objects, functions, and/or qualifiers supported in addition to the Highest

DNP Levels Supported (the complete list is described in the attached table):

Maximum Data Link Frame Size Maximum Application Fragment Size
(octets): (octets):
Transmitted: 292 Transmitted: 8192 (configurable via

(configurable via IPROP_DNP_TX_FRAGMENT_SIZE)
IPROP_DNP_TPDU_SIZE)
Received: 2048 (configurable via
Received: 292 (must be 292) IPROP_DNP_RX_FRAGMENT_SIZE)
Maximum Data Link Retries: Maximum Application Layer Retries:
None None
Fixed at Configurable, range 0 to any value
_______________________ (configurable via
Configurable, range 0 to any value IPROP_DNP_APPLICATION_RETRY)
(configurable via (Fixed is not permitted)
IPROP_DNP_DATALINK_RETRY)
Requires Data Link Layer Confirmation:
Never
Always
Sometimes If “Sometimes”, when?
______________________________________________
Configurable If “Configurable”, how? Configurable via

IPROP_DNP_DATALINK_CONFIRM
Requires Application Layer Confirmation:
Never
Always (not recommended)
When reporting event data (Slave devices only)
When sending multi-fragment responses (Slave devices only)
Sometimes If “Sometimes”, when?
______________________________________________

Configurable If “Configurable”, how? Configurable via
IPROP_DNP_APPLICATION_CONFIRM
Timeouts while waiting for:
Data Link Confirm None Fixed at _________

Variable Configurable
Complete Appl. Fragment None Fixed at _________
Application Confirm None Fixed at _________
Complete Appl. Response None Fixed at _________
Others: Configurable via IPROP_DNP_DATALINK_TIMEOUT,

IPROP_DNP_APPLICATION_TIMEOUT
Attach explanation if “Variable” or “Configurable” was checked for any timeout.
Sends/Executes Control Operations:
WRITE Binary Outputs Never Always Sometimes

Configurable
SELECT/OPERATE Never Always Sometimes
Configurable
DIRECT OPERATE Never Always Sometimes
Configurable
DIRECT OPERATE – NO ACK Never Always Sometimes
Configurable
Count > 1 Never Always Sometimes

Configurable
Pulse On Never Always Sometimes
Configurable
Pulse Off Never Always Sometimes
Configurable
Latch On Never Always Sometimes
Configurable
Latch Off Never Always Sometimes

Configurable
Queue Never Always Sometimes

Configurable
Clear Queue Never Always Sometimes
Configurable
Attach explanation if “Sometimes” or “Configurable” was checked for any operation.
FILL OUT THE FOLLOWING ITEM FOR MASTER DEVICES ONLY:
Expects Binary Input Change Events: N/A
Either time-tagged or non–time-tagged for a single event

Both time-tagged and non–time-tagged for a single event
Configurable (attach explanation)
FILL OUT THE FOLLOWING ITEMS FOR SLAVE DEVICES ONLY:
Reports Binary Input Change Events Reports Time-Tagged Binary Input

when no specific variation requested: Change Events when no specific variation
requested:
Never
Only time-tagged Never
Only non–time-tagged Binary Input Change with Time
Configurable to send both, one or Binary Input Change with Relative Time
the other (attach explanation). Configurable (attach explanation).
Configurable via Configurable via
IPROP_DNP_DEFAULT_VARIATION IPROP_DNP_DEFAULT_VARIATION
with parameter DFLT_BI_CHG with parameter DFLT_BI_CHG_TIME
Sends Unsolicited Responses: Sends Static Data in Unsolicited

Responses:
Never
Configurable (attach explanation) Never
Only certain objects When Device Restarts

Sometimes (attach explanation) When Status Flags Change
ENABLE/DISABLE UNSOLICITED No other options are permitted.

Function codes supported N/A, since unsolicited mode is not
supported.
Default Counter Object/Variation: Counters Roll Over at:
No Counters Reported No Counters Reported

Configurable (attach explanation) Configurable (attach explanation)
Default Object 16 Bits
______________ 32 Bits
Default Variation Other Value _____________
______________
Point-by-point list attached
Point-by-point list attached
Configurable via
IPROP_DNP_DEFAULT_VARIATION
Sends Multi-Fragment Responses: Yes No Configurable via IPROP_DNP_SINGLE_FRAGMENT
Figure 38. DNP Device Profile Document
Note that the DNP unsolicited mode is presently unsupported. However, the effort
required to enable and test unsolicited mode is not substantial. The entire framework for
unsolicited support is already present but has simply not been tested.
Table 28 displays all of the supported DNP objects, associated variations, and
command/response qualifiers that ProtocolPak supports.
Objects whose descriptions appear in bold are not supported. Support may be provided
for these objects in the future. Partial support already exists for a number of these
objects.
Table 28. DNP Device Profile

Object Variation Description Command Command Response Response
Functions Qualifiers Functions Qualifiers
1 0 Binary input – all variations 1, 22 00, 01, 06
1 Binary input 1 00, 01, 06 129, 130 00, 01
2 Binary input with status 1 00, 01, 06 129, 130 00, 01

2 0 Binary input change – all 1 06, 07, 08
variations
1 Binary input change 1 06, 07, 08 129, 130 17, 28
without time
2 Binary input change with 1 06, 07, 08 129, 130 17, 28
time
3 Binary input relative 1 06, 07, 08 129, 130 17, 28
change with time
10 0 Binary output – all
variations
2 Binary output status 1 00, 01, 06 129, 130 00, 01
12 0 Control block – all
variations
1 Control relay output block 3, 4, 5, 6 17, 28 129 Echo
2 Pattern control block 5, 6 17, 28 129 Echo
3 Pattern mask 5, 6 00, 01 129 Echo
20 0 Binary counter all 1, 7, 8, 9, 00, 01, 06
variations 10, 22
1 32-bit binary counter 1 00, 01, 06 129, 130 00, 01
3 32-bit delta counter 1 00, 01, 06 129, 130 00, 01
without flag
without flag
without flag
without flag
21 0 Frozen counter – all 1, 22 00, 01, 06
variations
1 32-bit frozen counter 1 00, 01, 06 129, 130 00, 01
3 32-bit frozen delta 1 00, 01, 06 129, 130 00, 01
counter
4 16-bit frozen delta 1 00, 01, 06 129, 130 00, 01
counter
without flag
without flag

11 32-bit frozen delta 1 00, 01, 06 129, 130 00, 01
counter without flag
22 0 Counter change event – all 1 06, 07, 08
variations
1 32-bit counter change 1 06, 07, 08 129, 130 17, 28
event without time
2 16-bit counter change 1 06, 07, 08 129, 130 17, 28
event without time
change event without
time
change event without
time
23 0 Frozen counter events – 1 06, 07, 08
all variations
event without time
event without time
3 32-bit frozen delta 1 06, 07, 08 128, 130 17, 28
counter event without
time
4 16-bit frozen delta 1 06, 07, 08 128, 130 17, 28
counter event without
time
30 0 Analog input – all 1, 22 00, 01, 06
variations
1 32-bit analog input 1 00, 01, 06 129, 130 00, 01
2 16-bit analog input 1 00, 01, 06 129, 130 00, 01
3 32-bit analog input without 1 00, 01, 06 129, 130 00, 01
flag
4 16-bit analog input without 1 00, 01, 06 129, 130 00, 01
flag
31 0 Frozen analog input – all 1, 22 00, 01, 06
variations
1 32-bit frozen analog 1 00, 01, 06 129, 130 00, 01
input
input
32 0 Analog change event – all 1 06, 07, 08
variations
1 32-bit analog change 1 06, 07, 08 129, 130 17, 28
event without time
event without time

event with time
event with time
33 0 Frozen analog event – all 1 06, 07, 08
variations
event without time
event without time
event with time
event with time
40 0 Analog output status – all 1 00, 01, 06
variations
1 32-bit analog output status 1 00, 01, 06 129, 130 00, 01
2 16-bit analog output status 1 00, 01, 06 129, 130 00, 01
41 1 32-bit analog output block 3, 4, 5, 6 17, 28 129 Echo
2 16-bit analog output block 3, 4, 5, 6 17, 28 129 Echo
50 1 Time and date 2 7 -- --
1 7 129 7
51 0 Time and date CTO – all
variations
1 Time and date CTO 129, 130 07
Unsynchronized time and 129, 130 07
date CTO
52 0 Time delay – all variations
1 Time delay coarse 129 07
2 Time delay fine 129 07
60 1 Class 0 (static) data 1 06
2 Class 1 data 1 06, 07, 08
20 , 21, 22 06
3 Class 2 data 1 06, 07, 08
20, 21, 22 06
4 Class 3 data 1 06, 07, 08
20, 21, 22 06
80 1 Internal indications 1 00, 01
2 00
index = 7

9.14.2 IEC101 Interoperability
This companion standard presents sets of parameters and alternatives from which
subsets have to be selected to implement particular telecontrol systems.
Certain parameter values, such as the number of octets in the COMMON ADDRESS of
ASDUs, represent mutually exclusive alternatives. This means that only one value of
the defined parameters is admitted per system.
Other parameters, such as the listed set of different process information in command
and in monitor direction, allow the specification of the complete set or subsets, as
appropriate for given applications.
This clause summarizes the parameters of the previous clauses to facilitate a suitable
selection for a specific application. If a system is composed of equipment stemming
from different manufacturers, it is necessary that all partners agree on the selected
parameters.
The selected parameters should be filled up ( ).
Note: In addition, the full specification of a system may require individual selection of
certain parameters for certain parts of the system, such as the individual selection of
scaling factors for individually addressable measured values.
To simplify the Protocol Implementation Document (PID) use the following conventions:
9.14.2.1 System or Device
9.14.2.2 Network Configuration (Network-Specific Parameter)

9.14.2.3 Physical Layer (Network-Specific Parameter)
Transmission speed (control direction):
Transmission speed (monitor direction):
9.14.2.4 Link Layer (Network-Specific Parameter)

(Network-specific parameter, all options that are used should be filled up ( ).
Specify the maximum frame length. If a non-standard assignment of Class 2 messages
is implemented for unbalanced transmission, indicate the type ID and COT of all
messages assigned to Class 2.
In this companion standard, frame format FT 1.2, single character 1, and the fixed
timeout interval are used exclusively.

Frame length
9.14.2.5 Application Layer

Transmission mode for application data
In this companion standard, mode 1 (least significant octet first), as defined in clause
4.10 of IEC 870-5-4, is used exclusively.
Common address of ASDU

(System-specific parameter)
The address field of the link and the common address of ASDU can have a different
number of bytes.
Information object address


Cause of transmission
Frame length
9.14.2.6 Selection of Standard ASDUs

Process information in monitor direction
(Station-specific parameter)

Process information in monitor direction with the Extension of Time tag

Process information in control direction
System information in monitor direction

System information in control direction


Parameter in control direction
File transfer

Type identifier and cause of transmission assignments
(Station-specific parameters)

• COT <45> := Unknown Cause of Transmission
9.14.2.7 Basic Application Functions

Station initialization
(Between Reset User ASDUs)
Cyclic data transmission

(It is the same cyclic transmission for all data.)
Read procedure

Spontaneous transmission
Link state between Controlling and Controlled station
General interrogation
(System- or station-specific parameter)
Counter General interrogation

Clock synchronization
Notes:
The controlled station reports the change of hour by sending a clock synchronization
message (ASDU 103) to the controlling station as Class 1 data, with a cause of
transmission Spontaneous (3).

When the controlling station sends a clock synchronization message to the controlled
station and the system (includes controlled station) is not synchronized with the GPS,
the clock synchronization response is positive.
station and the system (includes controlled station) is synchronized with the GPS, the
clock synchronization response is negative.
The clock synchronization can be sent before each event (this is configurable in the
Registry).
Command transmission
(Object-specific parameter)
Transmission of integrated totals

(Station- or object-specific parameter)

Parameter loading
Parameter activation
Test procedure
File transfer
File transfer in monitor direction
File transfer in control direction
Background scan

Acquisition of transmission delay
Management events priorities

See: T101 Standard Amendment 2 §7.2.2.2
9.14.3 IEC104 Interoperability

This companion standard presents sets of parameters and alternatives from which
subsets have to be selected to implement particular telecontrol systems.
Certain parameter values, such as the number of octets in the COMMON ADDRESS of
ASDUs, represent mutually exclusive alternatives. This means that only one value of
the defined parameters is admitted per system.
Other parameters, such as the listed set of different process information in command
and in monitor direction, allow the specification of the complete set or subsets, as
appropriate for given applications.
This clause summarizes the parameters of the previous clauses to facilitate a suitable
selection for a specific application. If a system is composed of equipment stemming
from different manufacturers, it is necessary that all partners agree on the selected
parameters.
The selected parameters should be filled up ( ).
Note: In addition, the full specification of a system may require individual selection of
certain parameters for certain parts of the system, such as the individual selection of
scaling factors for individually addressable measured values.
To simplify the PID, use the following conventions:

Reference Document:
Telecontrol equipment and systems – Part 5-104: Transmission protocols – Network
access for IEC60870-5-101 using standard transport profiles
Date : 2000-08-25
Paragraph 9: Interoperability
9.14.3.1 System or Device
9.14.3.2 Network Configuration (Network-Specific Parameter)

IEC104 meaningless.
9.14.3.3 Physical Layer (Network-Specific Parameter)

Transmission speed (control direction):
IEC104 meaningless.
Transmission speed (monitor direction):
IEC104 meaningless.
9.14.3.4 Link Layer (Network-Specific Parameter)

IEC104 meaningless.
9.14.3.5 Application Layer

Transmission mode for application data
In this companion standard, mode 1 (least significant octet first), as defined in clause
4.10 of IEC 870-5-4, is used exclusively.
Common address of ASDU
The Address field of the link and the common address of ASDU can have a different
number of bytes.

Information object address
Cause of transmission
Frame length
The maximum length of APDU is 253.
9.14.3.6 Selection of Standard ASDUs

Process information in monitor direction

Process information in monitor direction with the Extension of Time tag
Process information in control direction


System information in monitor direction
System information in control direction

Parameter in control direction


File transfer

Type identifier and cause of transmission assignments
(Station-specific parameters)

COT <45> := Unknown Cause of Transmission
9.14.3.7 Basic Application Functions

Station initialization
(Between Reset User ASDUs)
Cyclic data transmission

(It is the same cyclic transmission for all data.)
Read procedure

Spontaneous transmission
General interrogation
Counter General interrogation

Clock synchronization
Notes:
The controlled station reports the change of hour by sending a clock synchronization
message (ASDU 103) to the controlling station as Class 1 data, with a cause of
transmission Spontaneous (3).
station and the system (includes controlled station) is not synchronized with the GPS,
the clock synchronization response is positive.
station and the system (includes controlled station) is synchronized with the GPS, the
clock synchronization response is negative.

The clock synchronization can be sent before each event (this is configurable in the
Registry).
Command transmission
Transmission of integrated totals

(Station- or object-specific parameter)

Parameter loading
Parameter activation
Test procedure
File transfer
File transfer in monitor direction
File transfer in control direction
Background scan

Port number
9.14.4 Telegyr 8979 Interoperability

This section details the specific level of support that ProtocolPak provides for the
Telegyr 8979 protocol.
At the present time, change reporting is not handled. Therefore, all of the
“Change Report” function codes are unsupported.
Note: Some of the function codes marked as unsupported may indeed operate
correctly. However, these function codes have simply not been thoroughly tested and
are, therefore, not guaranteed to work. If you require a specific function code that is
currently listed as unsupported, contact Alstom Grid.
Telegyr 8979 spontaneous reporting is not supported.
Table 29. Telegyr 8979 Supported Function Codes

Function Code Exchange Name Supported
0 Analog Change Report No

1 Analog Force Report Yes
2 Analog Group Change Report No
3 Analog Group Force Report Yes
5 ADC Reference Report Yes
6 Indication Change Report No
7 Indication Force Report Yes
8 SOE Change Report No
9 SOE Force Report Yes
11 Digital Input Force Report Yes
12 Accumulator Change Report No
13 Accumulator Force Report Yes
14 SOE Log Change Report No
20 Analog Output Yes
21 SBO Select Yes
22 SBO Operate Yes
23 Digital Output Yes

Function Code Exchange Name Supported
24 Accumulator Freeze No
25 Pulse Output Yes
26 Pulse Train Output Yes
28 SBO Immediate Execute Yes
30 Restart RTU No
31 RTU Configuration No
32 Time Synchronization No
33 Time Bias No
34 Analog Deadbands No
35 Analog Group Define No
36 Accumulator Preset No
37 Continuation Request Yes
38 Repeat Last Message Yes
39 Firmware Configuration Yes
47 Table Read No
48 Table Write No
63 Exception Data Yes


E-Terracontrol 3.9 Reference Manual - Interfaces To External Systems

Uploaded by

Copyright:

Available Formats

You might also like

E-Terracontrol 3.9 Reference Manual - Interfaces To External Systems

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

E-Terracontrol 3.9 Reference Manual - Interfaces To External Systems

Uploaded by

Copyright:

Available Formats

e-terracontrol Reference Manual:

Interfaces to External Systems

Software Version: e-terracontrol 3.9

Copyright © 2015 ALSTOM Grid Inc. or Affiliate. All Rights Reserved.

2. ADO/SMP Interface Application ............................................................................ 3

3. DDEML/SMP Interface Application ..................................................................... 12

4. InterSite Data Application .................................................................................... 23

5. Modbus/SMP Interface Application .................................................................... 28

Proprietary – See Copyright Page iii

7. PI/SMP Interface Application ............................................................................... 52

8. ICCP Application .................................................................................................. 61

Proprietary – See Copyright Page iv

Proprietary – See Copyright Page v

Proprietary – See Copyright Page vi

Proprietary – See Copyright Page vii

Proprietary – See Copyright Page viii

Purpose of This Document

Who Should Use This Document

Structure of This Document

Proprietary – See Copyright Page ix

Proprietary – See Copyright Page x

Proprietary – See Copyright Page xi

Proprietary – See Copyright Page xii

Proprietary – See Copyright Page xiii

Table 1. e-terracontrol Interface Applications Data Mapping with External Systems

Proprietary – See Copyright Page 1 Overview

Proprietary – See Copyright Page 2 Overview

2.1 ADO/SMP Command-Line Argument

2.2 Starting the ADO/SMP Interface Using the Process Starter

Proprietary – See Copyright Page 3 ADO/SMP Interface Application

2.3 ADO/SMP Interface Application User Interface

Figure 1. ADO/SMP Interface User Interface Window

Proprietary – See Copyright Page 4 ADO/SMP Interface Application

2.4 ADO/SMP Interface Menu Bar

2.4.1 ADO/SMP Interface Debug Output Window

Figure 2. ADO/SMP Debug Output Window

Proprietary – See Copyright Page 5 ADO/SMP Interface Application

2.5 ADO/SMP Interface Configuration File Format

Table 2. Defined Resources for the ADO/SMP Interface

Proprietary – See Copyright Page 6 ADO/SMP Interface Application

Proprietary – See Copyright Page 7 ADO/SMP Interface Application

Table 3. Item Definition for the ADO/SMP Interface

Proprietary – See Copyright Page 8 ADO/SMP Interface Application

Proprietary – See Copyright Page 9 ADO/SMP Interface Application

2.5.1 ADO/SMP Interface Configuration File Example

Proprietary – See Copyright Page 10 ADO/SMP Interface Application

Proprietary – See Copyright Page 11 ADO/SMP Interface Application

Proprietary – See Copyright Page 12 DDEML/SMP Interface Application

Figure 3. DDEML/SMP Interface Window

3.2 DDEML/SMP Interface Menu Bar

Proprietary – See Copyright Page 13 DDEML/SMP Interface Application

Figure 4. DDEML/SMP Interface Debug Output Window

3.4 DDEML/SMP Interface Configuration File Format

Proprietary – See Copyright Page 14 DDEML/SMP Interface Application

Proprietary – See Copyright Page 15 DDEML/SMP Interface Application

Proprietary – See Copyright Page 16 DDEML/SMP Interface Application

Proprietary – See Copyright Page 17 DDEML/SMP Interface Application

Proprietary – See Copyright Page 18 DDEML/SMP Interface Application