Valmet (Tejas Series V) Master Protocol: Reference Manual

Reference Manual
VALMET (TEJAS Series V)

Master Protocol
Documentation for part number P-SMPR-0701
© 2012 Cooper Power Systems, LLC – All rights reserved.
The information in this document is subject to change without notice.
Cooper Power Systems

Energy Automation Solutions
730 Commerciale Street
Suite 200
Saint-Jean-Chrysostome, Quebec
Canada G6Z 2C5
Phone: +1.418.834.0009
Fax: +1.514.227.5256
Email: PSMO-sales@cooperindustries.com
Web: http://www.cooperpower.com
Technical Support: PSSJ-support@cooperindustries.com
S1120-29-1, version 6
Contents
1. Introduction ............................................................................................................................. 1
1.1 References .............................................................................................................................. 1
1.2 Document Overview ................................................................................................................. 1
2. Features.................................................................................................................................... 2
2.1 Communications....................................................................................................................... 2
2.2 Implementation Restrictions and Warnings ................................................................................ 2
3. Functions .................................................................................................................................. 3
3.1 Introduction ............................................................................................................................. 3
3.2 Binary information published via the RTDX ................................................................................ 3
3.2.1 General Description.................................................................................................... 3
3.2.2 Types of Binary Inputs ............................................................................................... 4
3.2.3 Pre-Configured Binary Inputs ...................................................................................... 4
3.3 Analog information published via the RTDX................................................................................ 5
3.3.2 Types of Analog Inputs .............................................................................................. 6
3.3.3 Pre-Configured Analog Inputs ..................................................................................... 6
3.4 Binary outputs controlled via the RTDX ...................................................................................... 7
3.4.2 Types of Binary Outputs ............................................................................................. 8
3.4.3 Pre-Configured Binary Outputs ................................................................................... 9
3.5 Analog outputs controlled via the RTDX ................................................................................... 10
3.5.1 General Description.................................................................................................. 10
3.5.2 Types of Analog Outputs .......................................................................................... 11
3.5.3 Pre-Configured Analog Outputs................................................................................. 11
3.6 Log Files ................................................................................................................................ 11
3.7 Statuses and Statistics ............................................................................................................ 12
3.8 Real-Time Traces ................................................................................................................... 15
3.9 SNMP Traps ........................................................................................................................... 15
3.9.1 Link Up/Down Traps ................................................................................................ 15
3.10 Listen Mode ........................................................................................................................... 16
4. Configuration Settings ........................................................................................................... 17
4.1 General Settings..................................................................................................................... 17
4.2 Analog Input Settings ............................................................................................................. 20
4.3 Binary Input Settings .............................................................................................................. 21
4.4 Counter Input Settings ........................................................................................................... 22
4.5 Analog Output Settings ........................................................................................................... 22
4.6 Binary Output Settings ........................................................................................................... 24
5. Multiple Instances .................................................................................................................. 26
6. Poll Cycle Management .......................................................................................................... 27
7. Protocol Management ............................................................................................................ 29
7.1 RTU Status Flags .................................................................................................................... 31
7.2 COS and ABE Counts .............................................................................................................. 31
7.3 RTU Configuration .................................................................................................................. 32
7.4 Binary Inputs ......................................................................................................................... 32
7.5 Analog Inputs ........................................................................................................................ 32
7.6 Accumulator Registers ............................................................................................................ 32
7.7 Analog Threshold Outputs ...................................................................................................... 32
7.8 Analog Outputs ...................................................................................................................... 32
7.8.1 Interactions with the end device ............................................................................... 33
VALMET (TEJAS SERIES V) MASTER PROTOCOL REFERENCE MANUAL ●i

7.9 Control Outputs ..................................................................................................................... 35
7.9.1 Interactions with the end device ............................................................................... 35
7.9.2 OPEN/CLOSE operations using two PULSE points ....................................................... 37
ii ● VALMET (TEJAS SERIES V) MASTER PROTOCOL REFERENCE MANUAL

Tables
Table 2-1 Communications Features ................................................................................ 2
Table 3-1 Binary Input Status Bits.................................................................................... 3
Table 3-2 Logical Binary Inputs ........................................................................................ 5
Table 3-3 Analog Input Status Bits ................................................................................... 5
Table 3-4 Logical Analog Inputs ....................................................................................... 7
Table 3-5 Binary Output Status Bits ................................................................................. 7
Table 3-6 Output Point States .......................................................................................... 8
Table 3-7 Logical Binary Outputs .................................................................................... 10
Table 3-8 Log Files .......................................................................................................... 12
Table 3-9 RTU states & statistics common to all VALMET TEJAS Series V RTUs ............ 13
Table 3-10 Scan States & Statistics Table ........................................................................ 15
Table 4-1 General Settings ............................................................................................. 19
Table 4-2 Analog Input Settings ..................................................................................... 21
Table 4-3 Binary Input Settings ...................................................................................... 22
Table 4-4 Counter Input Settings ................................................................................... 22
Table 4-5 Analog Output Settings ................................................................................... 24
Table 4-6 Binary Output Settings ................................................................................... 25
Table 5-1 RTU Priorities on Multidrop Links ................................................................... 26
Table 7-1 Protocol Requests ........................................................................................... 31
Table 7-2 RTU Status Flags ............................................................................................. 31
Table 7-3 All possible interactions with the end device for analog output control
requests .......................................................................................................... 35
Table 7-4 All possible interactions with the end device for binary output control
requests .......................................................................................................... 37
VALMET (TEJAS SERIES V) MASTER PROTOCOL REFERENCE MANUAL ● iii

1. Introduction
This manual provides the information required to install and set up the VALMET TEJAS Series-V
master protocol component on an SMP Gateway. The VALMET TEJAS Series-V master can be
used to poll any RTU that uses a Series-V protocol on standard asynchronous serial links in either
point-to-point or multidrop configurations.
The document has the following objectives:
 Serve as a requirement specification to the protocol implementation team.
 Serve as a requirement specification for the “Protocol Test Instruction Manual”.
 Allow clients to validate protocol features and limitations, in order to ensure that the
implementation fulfills their requirements.
 Remain as the final protocol implementation documentation, after appropriate updates
following implementation and testing.
1.1 References
The implementation of the VALMET TEJAS Series V master is based on the following protocol
specifications. It should be noted that some of these specifications are proprietary in nature and
cannot be disclosed to third parties without written approval from Valmet.
 Series V Communication Protocol, B8300-AAA-00005, Valmet Automation Inc., January 1992.
 TEJAS Scan Task, User’s Guide for series 3 and 5 RTUs, Quindar Products Limited, April 1996.
It is absolutely essential that you read and understand the above-mentioned

specifications before proceeding with the rest of this document. The material in this
document will be meaningless unless you are fully familiar with Series V protocols.
1.2 Document Overview
Chapter Description
2 This chapter presents the component’s communication features and enumerates

the restrictions and protocol features not implemented by the current version of
the VALMET TEJAS Series V master protocol component.
3 This chapter documents all the functions performed by the VALMET TEJAS
Series V master protocol component.
4 This chapter documents the configuration settings associated with the TEJAS
protocol component.
5 This chapter deals with multiple instances of the VALMET TEJAS Series V master
protocol component.
6 This chapter documents the polling cycle used to exchange information with the
RTU.
7 This chapter deals with protocol management.
VALMET (TEJAS SERIES V) MASTER PROTOCOL REFERENCE MANUAL ●1

2. Features
This chapter outlines the features provided by the VALMET TEJAS Series V master protocol
component.
2.1 Communications
The following communication features are available when connecting devices to the
SMP Gateway:
Feature Comment
Serial Ports The VALMET TEJAS Series V protocol component supports RS-232,
RS-422 and RS-485 interfaces at bit rates up to 115,200 b/s.
TCP/IP The VALMET TEJAS Series V protocol component supports TCP/IP
communications.
Multidrop Multiple instances of the VALMET TEJAS Series V protocol
component can share a single serial port, as long as different
addresses are used to identify the devices and as long as the
devices support such a feature.
Passthrough The VALMET TEJAS Series V protocol component allows for
Connections passthrough connections. Note that it is necessary to suspend link
activity to establish such a connection.
Listen Mode The VALMET TEJAS Series V master component can be configured
as a spy on a serial link. Also, listen mode can be enabled/disabled
dynamically using control operations on logical binary output points.
Serial Radios The VALMET TEJAS Series V protocol component supports
asynchronous communications using serial radios.
Table 2-1 Communications Features
2.2 Implementation Restrictions and Warnings

The VALMET TEJAS Series V master protocol implements all the features enumerated in section 2
and appendix A of the Series V Communication Protocol specifications, with the following
restrictions:
 Pulsed output control requests are not currently supported.
 A maximum of 10 simultaneous binary output and 10 simultaneous analog output control
requests can be active at any given time.
 The current implementation of the VALMET TEJAS Series V master protocol does not process
status flag information, other than to keep track of it in statistics tables (current state and
transition count). These statistics can be accessed using standard SMP Tools. The only
notable exception is the “RTU reset” bit that triggers a complete link re-initialization when
present.
The current implementation of the VALMET TEJAS Series V master protocol assumes that the
information received from the RTU (analog and binary information) is valid as long as the
checksum of the message that carries the information is valid. There are no mechanisms for
determining whether this is actually true or not (mechanisms such as card statuses, converter
statuses, reference statuses, etc.).
2● VALMET (TEJAS SERIES V) MASTER PROTOCOL REFERENCE MANUAL

3. Functions
3.1 Introduction
Like all master protocol components, the TEJAS component is launched by the SMP Gateway
using site-specific configuration settings. These settings, which must be provided for each
protocol instance implemented, are described in chapter 5. It is important that you become fully
familiar with them, as much of the component’s functionality and flexibility depend directly on
how it is configured.
The TEJAS protocol component produces the following site-related information:
 Physical and logical analog inputs published via the RTDX.
 Physical and logical binary inputs published via the RTDX.
 Counter inputs published via the RTDX. The values in the RTDX are delta values.
 Scan statistics resulting from the RTU scanning process. These can be reset at will.
 RTU statistics containing information obtained directly from the RTU.
 Various logs generated when specific events occur.
 Various real time traces that can be enabled/disabled on an individual basis.
The TEJAS protocol component also contributes to the control of site-related activities in the form
of:
 Binary (relay) outputs controlled by means of SELECT/EXECUTE requests.
 Analog outputs (set points) controlled using either SELECT/EXECUTE or DIRECT EXECUTE
requests.
The following sections describe in detail the exact nature and significance of the information
provided by the TEJAS protocol component and the control functions performed by it.
3.2 Binary information published via the RTDX

3.2.1 General Description
The TEJAS component manages the following information for each configured binary input:
 The input’s current state.
 A SMP Gateway-provided time tag of when the last change was detected.
 A status bit with the following significance:
Status Bit Description

Communications Failure Set to one when a correct reading cannot be obtained due to RTU
or communication problems. This bit is set at startup. It is also set
as soon as communications with the RTU are interrupted for any
reason. It is reset only when a valid state has been obtained from
the RTU.
Hardware Failure Set to one when a status/alarm subsystem failure indication is
reported via a RTU status bit. There is only one status bit for the
entire status/alarm subsystem, and only for the Micro1, Micro1E
and Camdac RTU models. This bit is unused (always reset) for
other RTUs.
Table 3-1 Binary Input Status Bits

3.2.2 Types of Binary Inputs
The TEJAS protocol components maintain and publish the following binary input related
information.
Normal (physical) binary inputs (type 0)

This information is obtained by scanning RTU status inputs using the various requests/responses
defined in the TEJAS protocol. Scanning is done on a regular basis using both exception reports
and explicit reading mechanisms. Normal physical binary input points are configured on an
individual basis. The RTU supports a maximum of 256 points numbered 0 to 255.
SMP Gateway-generated status bits (type 1)

This logical (or system) information is primarily related to communication statuses and is
automatically generated and maintained by the TEJAS protocol component.
Since the information provided by type 1 logical inputs is not device-dependent, there are no
status bits set.
Logical SMP Gateway status bits are not under your control and are pre-configured by the
SMP Gateway. They can however be enabled/disabled on an individual basis at configuration.
Currently supported status bits are enumerated in Table 3-2 at address 1.x.x.x.
RTU status bits (type 2)

This logical (or system) information is obtained from the RTU status byte (included in each RTU
response). RTU status bits are not under your control and are pre-configured by the
SMP Gateway. They can however be enabled/disabled on an individual basis at configuration.
Currently supported status bits are enumerated in Table 3-2 at address 2.x.x.x.
3.2.3 Pre-Configured Binary Inputs
Each VALMET TEJAS Series V master protocol instance contains a number of standard
configuration settings that are automatically included by the configuration console and that
cannot be edited by the user (you can however disable them if they are not required or not
used). These settings specify system level information of a binary nature and are not site
dependent.
Note that all tag names associated with these settings start with a triple underscore to distinguish
them from normal, site dependent settings. The addresses associated with these settings are
pre-determined and cannot be changed.
The following pre-configured binary inputs exist for each instance of the TEJAS protocol
component. Individual inputs can be disabled at configuration time if they are not required or not
used.
Name Address Description
___CommFail 1.0.0.0 Communication with RTU is not active.

___ScanEnabled 1.0.0.1 Scan task is active.
___ListenModeEnabled 1.0.0.2 Listen mode is enabled.
___CmndEnabled 1.0.0.3 Binary output control requests are allowed.
___SetpointEnabled 1.0.0.4 Analog output control requests are allowed.
___RtuPowerRst 2.0.0.0 RTU status: Power recycled

___RtuIllRequest 2.0.0.1 RTU status: Illegal request received from
SMP Gateway
___RtuIllConfig 2.0.0.2 RTU status: Questionable configuration
___RtuACCFrozen 2.0.0.3 RTU status: Accumulators have been frozen
___RtuHrdwrError 2.0.0.4 RTU status: Hardware malfunction
___RtuCntrlError 2.0.0.5 RTU status: Control selection failure
___RtuUnused1 2.0.0.6 RTU status: Unused
___RtuUnused2 2.0.0.7 RTU status: Unused
Table 3-2 Logical Binary Inputs
3.3 Analog information published via the RTDX

The TEJAS protocol component manages the following information for each configured analog
input:
 A raw 12 bit (2's complement or unipolar) reading
 A corresponding floating point reading in engineering units
 A SMP Gateway-provided time tag that corresponds to the time at which the currently
published value was obtained.
 A status bit with the following significance:
Communications Set to one when a correct reading/value cannot be obtained due to

Failure RTU or communication problems. This bit is set at startup. It is also
set when communications with the RTU are interrupted, whatever
the reason. When the link becomes operational again, it is reset
only when a valid reading has been obtained from the RTU.
Hardware Failure Set to one when an A/D subsystem failure indication has been
reported via an RTU status bit. There is only one status bit for the
entire A/D subsystem, and only for the Micro1, Micro1C, Micro1E
and Camdac RTU models. This status bit is not used for other RTU
types.
Over-range Set to one when an absolute value raw reading of 7FF (+/-2047) is
received, indicating that the A/D converter’s scale has probably
been exceeded. It is reset when the reading returns below 7FF.
Reference Error Not used. Always zero.
Table 3-3 Analog Input Status Bits
Initially, all analog inputs in the TEJAS analog database are initialized with a value of zero and
the Communications Failure status bit set. This bit will be reset when a first value is reported
following a successful scan.

3.3.2 Types of Analog Inputs
The TEJAS protocol components maintain and publish the following analog input related
information.
Normal (physical) analog input reading (type 0)

This information is obtained by scanning the RTU analog inputs using the various
requests/responses defined in the TEJAS protocol. Scanning is done on a regular basis using both
exception reports and explicit reading mechanisms. Normal analog points are configured on an
individual basis. The protocol supports up to 255 analog inputs numbered 0 to 254.
SMP Gateway logical analog counters (type 1)

This information is primarily related to communication statistics and is automatically generated
and maintained by the TEJAS protocol component.
This information is of the “logical counter” type. Scaling factors A and B are 1 and 0 respectively.
Dead bands are allowed to accommodate reduced reporting only once out of every N transitions.
All counters are reported as a 32 bit unsigned raw value or the equivalent floating-point value.
Slave protocols that wish to report this information to their respective master stations as 12 or 16
bit raw values should perform a “modulo” operation rather than a scaling operation.
Since the information provided by type 1 logical counters is not device-dependent, there are no
status bits set.
Logical analog inputs are pre-configured by the SMP Gateway and are disabled by default. They
can however be enabled/disabled on an individual basis at configuration time. Currently
supported logical counters are enumerated in Table 3-4 at address 1.x.x.x.
Logical counters are reset only when the SMP Gateway is reset or upon the reception of a logical
request specifying that they should be reset.
Metering analog counters (type 2)

This information is obtained by scanning the RTU accumulator inputs using the accumulator
freeze and scan requests/responses defined in the TEJAS protocol. Scanning is done on a regular
basis using a predefined timer or on reception of a user freeze request. The values received are
reported to the RTDX. Metering points are configured on an individual basis. The protocol
supports up to 256 analog inputs numbered 0 to 255.
3.3.3 Pre-Configured Analog Inputs
used). These settings specify system level information of an analog nature and are not site
dependent.
Note that the tag names associated with these settings start with a triple underscore to
distinguish them from normal, site dependent settings. The addresses associated with these
settings are pre-determined and cannot be changed.
The following pre-configured analog inputs exist for each instance of the TEJAS protocol
used.

___CommOKCount 1.0.0.0 Total number of transactions (with the RTU)
that were successfully completed.

___ChksumErrorCount 1.0.0.1 Total number of BCH errors.
___CommTimeoutCount 1.0.0.2 Total number of communication timeouts.
___CommLinkRstCount 1.0.0.3 Total number of times that the link with the
RTU was reset. This number will continuously
grow if successive connection attempts are not
successful.
___CmndOKCount 1.0.0.8 Total number of control requests on binary
output points that were successfully completed.
___CmndFailCount 1.0.0.9 Total number of control requests on binary
output points that were not successfully
completed. This count does not include control
request attempts that were refused by the
SMP Gateway. It only counts control request
attempts that failed at the RTU level.
___SetpointOKCount 1.0.0.10 Total number of control requests on analog
output points that were successfully completed.
Expressed as a 32 bit unsigned binary number.
___SetpointFailCount 1.0.0.11 Total number of control requests on analog
output points that were not successfully
completed. This count does not include control
requests attempts that were refused by the
SMP Gateway. It only counts control request
attempts that failed at the RTU level. Expressed
as a 32 bit unsigned binary number.
Table 3-4 Logical Analog Inputs
3.4 Binary outputs controlled via the RTDX

The TEJAS protocol component maintains up to date information for each configured binary
output. The most important information is related to the point’s current state and status.
A status bit can have the following significance:
Communications Set to one when a correct reading/value cannot be obtained due to

Failure RTU or communications problems. This bit is set at startup. It is
also set as soon as communications with the RTU are interrupted,
whatever the reason. When the link becomes operational again, it is
reset only when a valid reading has been obtained from the RTU.
Table 3-5 Binary Output Status Bits
A binary output point can have one of the following states:

State Description
BLOCKED The output point has been blocked so that no control operations
can be carried out on it. Possible reasons are detailed in other
attribute fields. They include known equipment failure,
maintenance, local operations only, inhibition by the master station,
etc. This state is stable and remains so until conditions change.
SELECTING The output point is currently being selected. This state is transitory.
SELECTED The output point has been selected. This state is stable and
remains so until a new request is received.
EXECUTING A control operation is currently being executed on the output point.
This state is transitory.
FAILED The output point is free for operation. However the last known
control request on this particular point failed. This state is stable.
FREE The output point is free for operation. The last known control
request on this particular point successful. This state is stable.
Table 3-6 Output Point States
Initially all binary outputs in the TEJAS analog database are initialized with the Communications
Failure bit set. This bit is reset as soon as communication with the RTU is established.
Binary output states change as a result of the VALMET TEJAS Series V master component
receiving a control request. Each time an output point’s state changes, a new copy of it is
broadcast to other protocol components. These, in turn, use the output point’s current state
information to validate whether or not an operation on the output point can be initiated and to
monitor the operation’s execution once it has been initiated.
Output operations imply the exchange of a control request between the request initiator (slave
protocol component) and the VALMET TEJAS Series V master protocol component.
All the steps carried out to completely process a control request (both by the slave and master
protocol components) are logged in the Command Log. You can always consult the log to obtain
more information after a control request has been refused or has failed.
3.4.2 Types of Binary Outputs
VALMET TEJAS Series V master protocol components support the following types of binary
outputs.
Normal binary outputs (physical relays) (type 0)

The TEJAS protocol supports the control of binary output points via SELECT/EXECUTE or DIRECT
EXECUTE commands (see chapter 7). Normal binary output points must be configured on an
individual basis before they can be controlled. Not more than 10 points can be controlled at a
given time.
The protocol component accepts a SELECT/EXECUTE control request combination or a single
logical DIRECT EXECUTE control request from other protocol components (such as the DNP
slave).
All TEJAS output points are of the PULSE-ONLY type. As a result, only PULSE, OPEN and CLOSE
requests are accepted from other protocol components. All other types of request messages are
refused with an ILLEGAL_CMND response.
Note: OPEN/CLOSE requests are accepted only when pair pairing is used. See section 4.6 for
further details.

Logical binary outputs (type 1)
The TEJAS protocol supports a number of logical binary outputs that can be used to control the
behavior of the protocol component in various ways.
Logical binary outputs are pre-configured and are disabled by default. They can however be
enabled/disabled on an individual basis at configuration time. Currently supported logical binary
outputs are enumerated in table 3-7 (address 1.x.x.x.).
Any type of control request message (SELECT/EXECUTE/DIRECT EXECUTE) on logical output
points is accepted, but only EXECUTE and DIRECT EXECUTE will result in the operation being
performed. Any type of execution request (OPEN, CLOSE or PULSE) is allowed to operate a
logical point. The only limitation is that it must be a control request message and it must specify
a known logical output point.
3.4.3 Pre-Configured Binary Outputs
used). These settings specify system level control request processing and are not site dependent.
Note that the tag names associated with these settings start with a triple underscore to
distinguish them from normal, site dependent settings. The addresses associated with these
settings are pre-determined and cannot be changed.
The following pre-configured binary outputs exist for each instance of the TEJAS protocol
used.

___ScanReset 1.0.0.0 Used to reset the entire scanning process,
including the communications link.
___ScanDisable 1.0.0.1 Used to disable scanning until further notice or
until the next SMP Gateway reset.
___ScanEnable 1.0.0.2 Used to enable scanning after it had previously
been disabled.
___ScanFast 1.0.0.3 Scan this RTU every other Cycle until further
notice. (Useful only when the RTU is on a
multidrop link).
Re-enables the scanning process if currently
disabled.
___ScanSlow 1.0.0.4 Scan this RTU every 10 cycles until further notice.
(Useful only when the RTU is on a multidrop link).
disabled.
___ScanNormal 1.0.0.5 Scan this RTU according to its normal pre-
configured priority. (Useful only when the RTU is
on a multidrop link).
disabled.
___CmndDisable 1.0.0.8 Used to disable command processing until further
notice or until the next SMP Gateway reset.

___CmndEnable 1.0.0.9 Used to enable command processing after it had
previously been disabled.
___SetpointDisable 1.0.0.10 Used to disable setpoint processing.
___SetpointEnable 1.0.0.11 Used to enable setpoint processing after it had
previously been disabled.
___LogCountersFrz 1.0.0.13 Used to provoke a general broadcast of all logical
counters maintained by the component. This is
particularly useful when the deadband setting
inhibits any spontaneous reporting of the logical
counters.
___LogCountersRst 1.0.0.14 Used to reset all logical counters to zero.
___LogCountersFrzRst 1.0.0.15 Used to combine a Freeze and a Reset in one
single operation.
___ListenModeDisable 1.0.0.16 Used to dynamically disable the listen mode, if
currently enabled.
___ListenModeEnable 1.0.0.17 Used to dynamically enable the listen mode, if
currently disabled.
Table 3-7 Logical Binary Outputs
3.5 Analog outputs controlled via the RTDX

Analog output information is obtained by polling the RTU on a regular basis and is distributed via
RTDX analog output objects. From there, other components can dispose of this information in
accordance with their own protocol requirements.
Analog outputs can also be modified (controlled) via RTDX analog output messages composed
and issued by other protocol components. When received by the TEJAS component, these
requests will be honored in accordance with the TEJAS protocol limitations. A series of response
messages (as well as new versions of the corresponding analog output object as it evolves) will
be returned via the RTDX so that the originator to follow the request’s evolution.
Analog output objects, as exchanged between protocol components via the RTDX, are derived
from analog input objects. This implies that they contain exactly the same information (raw
reading, real value in engineering units, multi-bit status, time tag, etc.), as well as some
additional information that exists only for the outputs. (See section 3.3 for further details
regarding analog inputs).
The additional information managed by analog output objects are:
 The last setpoint value, as issued by the SMP Gateway in binary raw value representation.
 The last setpoint value as issued by the SMP Gateway in real engineering units.
 The current state of the analog output. Possibilities are identical to those that exist for binary
outputs. (See Table 3-6).
Note that, after some time, the setpoint value, as issued by the SMP Gateway, may or may not
be the same as the actual analog reading obtained by polling the RTU analog outputs. Some of
the typical factors that could explain differences between the two values are:
 The RTU has not yet been polled since the last setpoint control request.
10 ● VALMET (TEJAS SERIES V) MASTER PROTOCOL REFERENCE MANUAL

 The RTU (or another control station) is itself changing the analog output.
 The requested setting was not accepted by the RTU.
 The requested setting has not yet been applied by the RTU.
When receiving requests to operate analog outputs, other protocol components may first consult
the analog object’s current state to determine whether or not the request will be accepted. If the
verification is positive, the component must issue an analog output request message to the
TEJAS component to actually operate the point.
3.5.2 Types of Analog Outputs
The TEJAS protocol components support the following types of analog outputs:
Normal (physical) analogs (physical relays) (type 0)

The TEJAS protocol supports analog control points using either the DIRECT EXECUTE command
or a pair of ARM/OPERATE commands. Normal analog output points must be configured on an
individual basis before they can be controlled.
Regardless of the point type (direct or not), the TEJAS component accepts a SELECT/EXECUTE
command combination or a single logical DIRECT EXECUTE command from other protocol
components (such as the DNP slave component).
No other analog output types are currently supported.

Other types could, for example, include logical setpoints to be used by the protocol component
itself. This would be equivalent to some form of dynamic configuration.
3.5.3 Pre-Configured Analog Outputs
There are currently no pre-configured analog outputs in the VALMET TEJAS Series V master
protocol component
3.6 Log Files

The TEJAS master maintains at least the following special Log Files (other than those that all
masters/slaves support by default):
Log Entries made by the TEJAS Protocol Component

Startup  Illegal headers and/or versions for information found in the
configuration files.
 Indications of the number of I/O points of each category that should
have been configured but that were ignored because of errors in the
configuration file.
 Any problems encountered when establishing links with the various
framework interfaces.
 Any other initialization problem.
 An indication that initialization was completed successfully, when this is
the case.
Control  All detailed control request processing related activities, along with a
success or failure status for each individual step.
 All new information received from the RTU about the current state of
the relay outputs.
VALMET (TEJAS SERIES V) MASTER PROTOCOL REFERENCE MANUAL ● 11

Log Entries made by the TEJAS Protocol Component
Protocol  Various abnormalities or errors that are detected when communicating
with the RTU. To prevent log overflow, only the first occurrence of each
type of error since the last link reset will be logged with an “At least one
case of ….” mention.
Table 3-8 Log Files
3.7 Statuses and Statistics

The VALMET TEJAS Series V master maintains RTU statuses and statistics that can be viewed
using standard SMP Tools. Most of the information in this table is received directly from the RTU.
About half of this information is common to all types of TEJAS RTUs and is documented in the
table below. The other half reflects the contents of the extended RTU diagnostic codes that are
obtained in response to a STATUS CLEAR command. These codes (32 in total) are different for
each type of RTU. They are documented in Valmet’s original protocol documentation.
Name Attributes Description

RTU Information
Instance Name Static Specifies the instance to which these

statistics apply.
RTU type Static Specifies the RTU Type as configured
(Micro/1/1C/1E/1L, Camdac, Landac or
Wesdac D20).
RTU Address Static Specifies the RTU’s link address (as
configured).
Protocol Static Valmet Series V.
Checksum type Static LRC or CRC-16 (as configured).
Analog Input qty Dynamic Number of analog inputs, as received from
the first RTU configuration request.
Status Input qty Dynamic Number of status/alarm inputs, as received
from the first RTU configuration request
Accumulator qty Dynamic Quantity of accumulator inputs, as received
from the first RTU configuration request.
RTU status bits
COS Queue overflow Dynamic with reset The number of times that the COS-Queue
count overflow status flag has been received since
the last SMP Gateway startup or counter
reset.
Selection failure flag Dynamic The current state of the Selection Failure
status flag.
Selection failure Dynamic with reset The number of times that the Selection
count Failure status flag has been received since
the last SMP Gateway startup or counter
reset.

Hardware Dynamic The current state of the Hardware
malfunction flag Malfunction status flag.
Hardware Dynamic with reset The number of times that the Hardware
malfunction count Malfunction status flag has been received
since the last SMP Gateway startup or
counter reset.
Accumulator Dynamic The current state of the Accumulator
freeze/reset flag Freeze/Reset status flag.
Accumulator Dynamic with reset The number of times that the Accumulator
freeze/reset count Freeze/Reset status flag has been received
counter reset.
Bad RTU Dynamic The current state of the Bad RTU
configuration flag Configuration status flag.
Bad RTU Dynamic with reset The number of times that the Bad RTU
configuration count Configuration status flag has been received
counter reset.
Power cycled flag Dynamic The current state of the Power Cycled status
flag.
Power cycled count Dynamic with reset The number of times that the Power Cycled
status flag has been received since the last
SMP Gateway startup or counter reset.
Table 3-9 RTU states & statistics common to all VALMET TEJAS Series V RTUs
The VALMET TEJAS Series V master also maintains scan statuses and statistics that can be
viewed using standard SMP Tools. Most of the information in this table is either configuration
information or is directly obtained from the scanning process. The significance of these statistics
is as follows:

Configuration
Instance name Static The instance to which these statistics

apply.
Device prefix Static The device prefix (s configured).
Protocol Static The RTU Type (Micro/1/1C/1E/1L, Camdac,
Landac or Wesdac D20).
Listen mode Static Specifies whether or not the listen mode is
active (as configured).
RTU address Static The RTU’s link address (as configured).

Maximum transaction Static The size of the largest request/response
Size that is allowed (as configured). This size in
turn determines how requests for all the
inputs of one particular type will be
subdivided into N requests to cover the
entire address range without exceeding the
maximum size limitation.
Exception scan interval Static The exception scan interval (as
(ms) configured).
AI/BI/Metering/AO scan Static The integrity scan interval for analog
intervals inputs, binary inputs, metering inputs and
analog outputs, respectively (as
configured).
Rx timeout (ms) Static The reception timeout (as configured).
Rx retry count Static The retry count before declaring link
defective (as configured).
Select recall timer Static The desired selection recall timer (as
configured).
Checksum type Static LRC or CRC-16 (as configured).
Report by exception of Static The report by exception of analog values
AI (as configured).
Selection timeout (ms) Static The selection timeout (as configured).
Scan process info
Current scan status Static The current scan status.

Scan priority Static The instance’s configured scan priority.
(configured)
Scan priority (ordered) Dynamic The instance’s scan priority as indicated by
the master station (takes precedence over
the configured priority).
Scan priority (current) Dynamic The instance’s current priority (can be
higher or lower than expected based on
current operation and link state).
Commands enabled Dynamic A boolean that indicates whether relay
control requests are currently enabled.
They can be disabled via a logical
command output.
Setpoints enabled Dynamic A boolean that indicates whether setpoints
commands are currently enabled. They can
be disabled via a logical command output.
Link reset count Dynamic with reset The number of times that the link was
reset after having been active for at least
one full cycle.

Tx Statistics
Counters Dynamic with reset The number of times each type of request
was sent out since the last statistics reset.
Rx statistics
Counters Dynamic with reset The number of times each type of

response was received since the last
statistics reset.
Logical command
counts
Counters Dynamic with reset The number of times each possible logical
command was received since the last
statistics reset.
Table 3-10 Scan States & Statistics Table
3.8 Real-Time Traces

The VALMET TEJAS Series V master protocol component maintains a very detailed “application
level” scan trace. This trace decodes and displays full message contents in “application” terms. It
can be combined with the communication component (in hexadecimal characters) and
System/Real Time Data Exchange traces to monitor all activities of a component.
3.9 SNMP Traps

SNMP traps are messages that are automatically sent to selected SNMP clients when specific, out
of the ordinary, events occur. They are the equivalent of alarms.
SNMP traps are automatically sent by the VALMET TEJAS Series V master component to advise
the network management team of problems that occur during the normal operation cycle. The
team can then take action based on the seriousness of the problems reported.
Refer to the SMP Gateway User Manual, S1120-10-1, for details SNMP configuration.
3.9.1 Link Up/Down Traps
A SNMP link down trap indicates that the communication with the end device could not be
established, or was established but is now broken.
An SNMP link up trap indicates that the communication with the end device has been established
for at least 5 seconds.
With this mechanism, different problems can be diagnosed, such as a faulty or badly connected
physical cable, an end device that is configured incorrectly or not powered up, an erroneous
communication or network configuration, a very noisy electrical environment that corrupts the
data stream, etc.
SNMP link down traps are generated under the following conditions:
 The communication with the end device could not be established after numerous attempts
during the 60 seconds following the VALMET TEJAS Series V master component acquisition
startup.
 The communication was established but then failed. In this case, the link down trap is
generated only if a previous link up trap was sent.

SNMP link up traps are generated only when communication with the end device is established
for at least 5 seconds.
Once a link down trap has been sent, subsequent traps will be generated only if the
communication is established and a link up trap is sent, followed by a communication breakdown.
Thus, an SNMP client won’t be notified more than once for a single communication failure.
The same applies to link up traps, i.e. subsequent traps will be generated only if the
communication is broken and a link down trap is sent, after which the communication is
established and maintained for at least 5 seconds.
The link up/down trap mechanism is automatically suspended if the acquisition is disabled, either
by a logical command or by a pass-thru connection. The link up/down trap mechanism is
automatically restarted when the acquisition is resumed, via the same mechanisms.
3.10 Listen Mode

The VALMET TEJAS Series V master component can be configured to operate as a spy on a serial
link, i.e. it can be configured to be in listen mode. This means that it cannot transmit over the
serial link it is using. Listen mode can be dynamically enabled/disabled, via control operations on
logical binary output points (see section 3.4.3).
The following restrictions apply to this mode:
 All output pins of the listen mode serial link port are placed in high impedance mode to avoid
hardware conflicts with the primary link.
 Control output operations are disabled.
 Since the TEJAS protocol responses are not self-contained and are request-dependent, the
VALMET TEJAS Series V master component must listen for the request sent from the primary
link to interpret the device response intelligently. Thus, 2 serial communication ports are
required. The first listens for the primary link request and the second listens for the device
response. A special cable is needed for this connection.
 Communication link failures are detected in two ways:
 If the VALMET TEJAS Series V master component doesn’t see any primary link request
sent over the link for a period equal to (Rx Retry Count + 1) * Rx Timeout Timer,
the link is declared defective.
 If the VALMET TEJAS Series V master component doesn’t receive a valid response from
the device for Rx Retry Count + 1 consecutive requests sent by the primary link, the
link is declared defective.
Remember that the basic idea in using a master component in listen mode is to spy on another
link that already controls the acquisition cycle with the RTU. Thus, the configuration of the
protocol instance used in listen mode must be compatible with the information that is exchanged
on the primary link.

4. Configuration Settings
This chapter enumerates the configuration settings to be specified for each VALMET TEJAS Series
V master protocol instance. The SMP Config software program is generally used to define these
settings.
4.1 General Settings

Each instance of this slave protocol component contains general settings, which set the general
behavior of the component. The following table shows the general settings for the VALMET
TEJAS Series V master protocol.
Setting Description
Device Prefix A string used as a prefix for all the I/O point names supported by
the device. This prefix ensures that every I/O point name in a
system is unique. Each device monitored by a system must have its
own, unique device prefix.
Range: 1 to 19 ASCII characters
Default value: none
Listen Mode A checkmark indicates that the master protocol component is in
listen mode.
Range: checkmark / no checkmark
Default value: no checkmark
RTU Address A valid RTU number. RTU number 0 is reserved for station
broadcasts.
Range: Wesdac D20: 1 to 32,767
Others: 1 to 127
Default value: 1
RTU Type The type of RTU. This value is used to determine the appropriate
interpretation of the detailed RTU status flags. Type Wesdac D20
also specifies 2-byte address support. You choose the type in a
drop-down list.
Allowed values: Micro 1
Micro 1C
Micro 1E
Micro 1L
LANDAC
CAMDAC
WESDAC D20
Default value: LANDAC
Scan Priority Useful only when the RTU is on a multidrop link that is shared with
other RTUs. Priority 0 is the highest priority, priority 1 is normal
priority, and priorities 2 to 100 are lower priorities. See Table 5-1
for an explanation of how scanning works, based on the priority
assigned to the device.
Allowed values: 0 to 100
Default value: 1

Setting Description
Scan Interval Specifies the interval, in milliseconds, between successive exception
polls. A value of 0 means that there will be no delay.
Range: 0 to 30,000 milliseconds
Default value: 1000 milliseconds
AI Scan Interval Specifies the interval, in seconds, between successive analog input
scans. A value of 0 means that there will be no delay. If reporting
by exception is allowed (see RBE Disabled), this scan must be
considered an integrity scan; otherwise, the scan determines the
rate at which analog input data is refreshed.
Range: 0 to 86,400 seconds (1 day)
Default value: 300 seconds (5 minutes)
BI Scan Interval Specifies the interval, in seconds, between successive binary input
(status) scans. A value of 0 means that there will be no delay. This
scan must be considered as an integrity scan.
Metering Scan Interval Specifies the interval, in seconds, between successive accumulator
scans. A value of 0 means that there will be no delay.
Range: 0 to 2,629,800 seconds (1 month)
AO Scan Interval Specifies the interval, in seconds, between successive analog output
scans. A value of 0 means that there will be no delay.
Rx Timeout Timer Specifies the time allowed, in milliseconds, for the reception of a
response following the transmission of a request to an RTU. The
start of a response must be received prior to this interval, or a
timeout is declared and another (or the same) request is issued.
Setting a short timeout may cause the link to operate erratically
(timeout declared even though the response is still coming). Setting
a long timeout may cause inefficiencies, with a considerable amount
of bandwidth wasted when communication errors occur.
Rx Retry Count Specifies the number of consecutive times a bad response, or no
response, must be received before a communications failure is
declared and an attempt is made to re-initialize the link.
Range: 2 to 100
Default value: 5
Delay Between Tx Specifies the minimum delay, in milliseconds, between two
successive transmissions.
Range: 0 to 60,000 milliseconds (1 minute)

Setting Description
Select Recall Timer Specifies the maximum time allowed, in milliseconds, between a
select request and a corresponding execution request. This time will
actually be used in each select request sent to the RTU. RTUs will
automatically cancel any select in progress if the execute request is
not received within this specified timeout period.
Max Trans. Size Specifies the maximum response size that will be accepted from the
RTU. This setting is used to determine how many exceptions will be
polled for at a time, and how many analog or binary addresses will
be scanned at a time. Multiple scans, interleaved in time, will be
used if the complete information cannot be reported in a single
scan, due to limitations imposed by this setting.
Range: 100 to 1000 bytes
Default value: 200 bytes
CRC Specifies the type of security coding used by the RTU. A checkmark
indicates CRC-16; the absence of a checkmark indicates LRC.
Default value: checkmark
RBE Disabled A checkmark disables report by exception of analog values. Some
RTUs do not support this feature. When report by exception is
disabled, the AI Scan Interval setting should not be set to 0,
unless there are no analog inputs to be scanned.
Selection Timeout The number of milliseconds during which a command can be issued
after an output point has been successfully selected. If the timeout
period expires, the control request is refused. A value of 0 disables
the selection timeout.
Range: 0 to 2,147,483,647 milliseconds (approx. 25 days)
Default value: 10,000 milliseconds
Notify When Ready A checkmark activates the "initial general interrogation completed"
notification mechanism.
This mechanism allows slave components (those configured to do
so) to wait before allowing connections from a master station, until
either the master components complete their first general
interrogation or there is a timeout, if the communication cannot be
established. This means that after an SMP Gateway reboot, the
master station does not see any useless transitions resulting from
system initialization.
Table 4-1 General Settings

4.2 Analog Input Settings
Each instance of the master protocol component may contain several analog input points. Analog
input settings tell the component how to process data retrieved from the device. The following
table shows the analog input settings for the VALMET TEJAS Series V master protocol.
Setting Description
Name The tag name associated with this analog input point. This name is
preceded by the device prefix, as specified in the general settings.
The device prefix, coupled with the tag name, ensures that the
point is unique among all devices managed by the system.
Default value: none
Address Specifies the hardware address assigned to the point.
Range: 0 to 255
Default value: 0
Disabled When this setting contains a checkmark, the point is ignored by the
protocol component. You can use this flag, for example, to
temporarily eliminate points due to hardware problems.
Unipolar Defines how raw analog values should be processed. A checkmark
specifies 12-bit unipolar readings, i.e., absolute positive values,
whereas the absence of a checkmark specifies 12-bit bipolar, i.e.,
2's complement readings.
Scale Scaling factor used to convert raw 12-bit values to significant
engineering units (floating point). The following equation is used:
Floating-point value =
(raw value * scale) + offset
Range: –3.4E38 to 3.4E38, not 0.0
Default value: 1.0
Offset The processing performed to convert raw 12-bit values to
significant engineering units (floating point). The following equation
is used:
Range: –3.4E38 to 3.4E38
Default value: 0.0
SMP Deadband Only changes greater than the deadband value are reported to the
slaves, unless the value itself is smaller than the deadband (this
ensures that small variations around 0 are reported so that, for
example, reported values do not remain fixed at .01 when they are,
in fact, 0).
Range: 0.0 to 3.4E38
Default value: 0.0, which implies that all transitions, no matter
how small, are reported.

Setting Description
Units A unit type (optional and used only by some of the SMP Tools).
Allowed values: As shown in the drop-down list
Default value: Undefined
RTU Deadband A default RTU threshold to be downloaded to the RTU at link
initialization time. A value of 0 implies that no new thresholds
should be downloaded and that the default RTU threshold (as
initialized by the RTU itself) should be used.
Range: 0 to 255
Default value: 0
Description An optional point description. Although recommended, this
description is not mandatory, since it is only used by the SMP Tools.
Range: 1 to 63 characters
Default value: none
Table 4-2 Analog Input Settings
4.3 Binary Input Settings

Each instance of the master protocol component may contain several binary input points. Binary
input settings tell the component how to process data retrieved from the device. The following
table shows the binary input settings for the VALMET TEJAS Series V master protocol.
Setting Description
Name The tag name associated with this binary input point. This name is
Default value: none
Range: 0 to 255
Default value: 0
Inverted Pol. Put a checkmark to have the protocol component invert the polarity
of the binary input before proceeding with any reporting.

Setting Description
Default value: none
Table 4-3 Binary Input Settings
4.4 Counter Input Settings

Each instance of the master protocol component may contain several counter input points.
Counter input settings tell the component how to process data retrieved from the device. The
following table shows the counter input settings for the VALMET TEJAS Series V master protocol.
Setting Description
Name The tag name associated with this counter input point. This name is preceded
by the device prefix, as specified in the general settings. The device prefix,
coupled with the tag name, ensures that the point is unique among all devices
managed by the system.
Default value: none
In the range specified below for Wesdac D20, 200 represents the first
Sangamo counter.
Range: Wesdac D20: 0 to 199 (counter input)
200 to 255 (Sangamo BCD counter)
Others: 0 to 255
Default value: 0
Disabled When this setting contains a checkmark, the point is ignored by the protocol
component. You can use this flag, for example, to temporarily eliminate points
due to hardware problems.
Description An optional point description. Although recommended, this description is not
mandatory, since it is only used by the SMP Tools.
Default value: none
Table 4-4 Counter Input Settings
4.5 Analog Output Settings

Each instance of the master protocol component may contain several analog output points.
Analog output settings tell the component how to control the device. The following table shows
the analog output settings for the VALMET TEJAS Series V master protocol.

Setting Description
Name The tag name associated with this analog output point. This name
is preceded by the device prefix, as specified in the general
settings. The device prefix, coupled with the tag name, ensures that
the point is unique among all devices managed by the system.
Default value: none
Range: 0 to 63
Default value: 0
Direct Execute A checkmark indicates that direct execute commands are to be
used for this output point. If there is no checkmark, select/execute
commands will be used to operate the point.
Unipolar Defines how raw analog values should be processed. A checkmark
specifies 12-bit unipolar readings, i.e., absolute positive values,
whereas the absence of a checkmark specifies 12-bit bipolar, i.e.,
2's complement readings.
Scale Scaling factor used to convert raw 12-bit values to significant
engineering units (floating point). The following equation is used:
Range: –3.4E38 to 3.4E38, not 0.0
Default value: 1.0
Offset The processing performed to convert raw 12-bit values to
significant engineering units (floating point). The following equation
is used:
Range: –3.4E38 to 3.4E38
Default value: 0.0

Setting Description
Deadband Only changes greater than the deadband value are reported to the
slaves, unless the value itself is smaller than the deadband (this
ensures that small variations around 0 are reported so that, for
example, reported values do not remain fixed at .01 when they are,
in fact, 0).
Range: 0.0 to 3.4E38
Default value: 0.0, which implies that all transitions, no matter
how small, are reported.
Default value: none
Table 4-5 Analog Output Settings
4.6 Binary Output Settings

Each instance of the master protocol component may contain several binary output points. Binary
output settings tell the component how to control the device. The following table shows the
binary output settings for the VALMET TEJAS Series V master protocol.
Setting Description
Name The tag name associated with this binary output point. This name is
Default value: none
Range: 0 to 255
Default value: 0
Master Duration A checkmark indicates that the activation time specified by the
Allowed master station should be used. If there is no checkmark, the
configured RTU activation time (see Activation Time) is used.
Default value: checkmark

Setting Description
Activation Time Specifies the time, in milliseconds, to be used when opening or
closing an output. If the value is 0, the RTU default duration is
used. If the value is not 0, the specified activation time is rounded
off to the nearest TICK multiple before being applied to an output
operation.
Points Pairing Indicates the output control operations supported for this point,
i.e., operations that can be forwarded to the end device.
Configuration of pairs allows slave protocol components to perform
open/close operations on either point in the pair. The point must be
configured as a member of an open/close pair, and there must be
another point in the same pair, which is configured in a
complementary way, i.e., one “Open” point and one “Close” point.
The two points of an open/close pair are linked together using the
Open/Close Pair setting, so they don’t have to be consecutive.
Open/close operations can be performed on either point of the pair,
giving the same results; an open operation results in a pulse
operation on the “Open” point of the pair, and a close operation
results in a pulse operation on the “Close” point of the pair. See
section 7.8.1 - Interactions with the end device.
Allowed values: None
Open
Close
Default value: None
Open/Close Pair Indicates the number of the open/close pair, if supported. This
setting is used to combine two pulse points, in order to allow
open/close operations on either of the two points.
Only two points can use the same OPEN/CLOSE pair number.
Allowed values: 0 not assigned
1 to 65,535 pair number
Default value: 0
Default value: none
Table 4-6 Binary Output Settings

5. Multiple Instances
There is no practical limit to the number of TEJAS RTUs that can be simultaneously supported by
the SMP Gateway. Multiple RTUs can be connected to individual serial links or regrouped on
multidrop links in any combination. However, each RTU requires a separate instance of
configuration settings. Moreover, only RTUs of the same type can be combined on the same link.
When several TEJAS RTUs share a single multidrop link, the Scan Priority setting will dictate
how the RTU shares the link with the other RTUs on the same link (this setting is ignored for
point to point links). Scanning priorities are defined as follows:
Priority Description
0 High priority RTU. The RTU has a turn every second scan. If several RTUs have
this priority, they all receive a turn on the link, followed by a single turn for the
next normal priority RTU, followed once again by a turn for all high priority
RTUs. This feature is to be used for RTUs with very high priority only.
1 Normal priority RTU. All RTUs with this priority receive an equal turn on the
link. This is the default setting.
N Low priority RTU. RTUs with this priority receive only one turn out of every N
turns that they would have received had they been normal priority RTUs.
Table 5-1 RTU Priorities on Multidrop Links
The scanning priority can also be altered dynamically for one of the following reasons:
 A logical output request has been received to place the RTU on FAST or on SLOW scan.
 The scan task is engaged in activities that require a higher than normal priority. This is the
case when a SELECT output request has been issued and an EXECUTE request is pending. It
is also the case when the link is being initialized after a link reset.
 The scan task has decided that the link or the RTU is not responding. The RTU is then
temporarily shifted to low priority until a first response is received.
Note that the scan task will maintain statistics on the minimum, current, and maximum time
periods between two turns on the link. These statistics, as well as the pre-configured and
currently used priority, can all be viewed using the SMP Tools.

6. Poll Cycle Management
The VALMET TEJAS Series V master manages the RTU polling cycle according to the following
principles:
 The protocol is half duplex.
 The RTU sends data only in response to a data request.
 Each request is answered (unless the request is broadcast to all RTUs).
The standard response processing rules are:

 If a request is broadcast (RTU address zero), no response is expected.
 A response is valid only if it arrives within a specified time limit. If it does not, the reception
status is TIMEOUT.
 A response is valid only if is the right size. If it is not, the reception status is BAD_LENGTH.
The length of the expected response is determined by the request, unless bits S5, S2 or S1
are set in the second byte of the response (the RTU status flags). In this case, the response
only has 4 or 5 bytes (depending on checksum types).
 A response is valid only if it has the right LRC or CRC. If it does not, the reception status is
BAD_CHECKSUM.
 The overall message format must be coherent and as expected. If it is not, the reception
status is BAD_FORMAT.
 The same requests are re-issued if the reception status is not correct.
 Whatever the reason, the link is reset from scratch if too many consecutive bad reception
statuses are received, too many being the number of retry counts configured.
Link initialization occurs under the following circumstances:

 The SMP Gateway is being restarted.
 The communication link is being reset due to too many consecutive errors of any type.
 The RTU has indicated that it was restarted. (Normally this is first detected as a
communications failure, but if it is not, the link resets anyways).
Link initialization procedures are identical, regardless of what caused the initialization to occur.
The link initialization procedures are as follows:

 Initialize the physical link.
 Exchange an RTU Configuration request to establish that the RTU is connected before
proceeding (and, incidentally, update the RTU MIB). The request is re-issued at regular
intervals until a successful response is received.
 Download all configured threshold values (unless RBE has been disabled). Only the analog
points for which the threshold has been configured at non-zero values will be updated.
 Perform a complete integrity scan on AI/BI/AO points and update all the databases with this
initial information.
The link is not considered initialized until all the above steps have been successfully completed, in
the order mentioned above. Once the link has been initialized, and as long as it remains active,
the regular polling cycle is used on a continuous basis.

The regular polling cycle is as follows:
 If necessary, manage any outstanding binary or analog selection status according to the
timeout mechanism.
 Process all (if any) new analog or binary selection requests.
 Process all (if any) new binary or analog execute requests.
 Perform a metering cycle, if it is the appropriate time to do so.
 Perform a cyclical integrity scans, if it is the appropriate time to do so.
 If the previous POLL request was successful or if a successful integrity scan was completed,
send a POLL with bits COSR and ABER set to 1.
 Send a POLL with bits COSR and ABER set to 0.
A metering cycle consists of the following requests and responses:

 Clear status bit S3, opcode 0x0B
 Accumulator freeze, opcode 0x07
 Accumulator scan, opcode 0x02
Once a complete or partial integrity scan request has been issued, no poll requests can be issued
before a completely valid response has been received. If a valid response is not received, the
scan request must be repeated before poll requests can once again be sent out.
Immediately after the normal polling cycle is abandoned to cause a link reset, all RTU I/O points
are tagged as being defective due to communications failure.
A Fast Scan mode is entered (no delay between requests and no switch to another RTU on the
link) whenever a binary or analog control request is active or whenever a communications error
prevents a normal poll cycle from completing.
Requests for all data include the following commands: opcode 1 (analog input scan), and opcode
3 (status point scan) and opcode 28 (analog output scan). The requests may be made in several
passes for large RTU configurations to reduce the maximal size of any transaction. If so, they are
evenly distributed in time to continue providing optimal response times on exception type
information.
In the absence of any special activity, a normal Poll request is composed of the following
requests:
 opcode 14 (analog change count request). This request returns the number of analog and/or
status exceptions that occurred at the RTU.
 opcode 10 (or opcode 30) (status point change dump) if the RTU indicates that it has status
input exceptions.
 opcode 15 (analog change dump) if the RTU indicates that it has analog input exceptions.

7. Protocol Management
The following subsections outline the various object mappings associated with the TEJAS
protocols as well as various management issues for each different object type. The following
table indicates which protocol elements are or are not currently implemented.
Implemented OpCode Description

Yes 1 Analog scan. Used under the following circumstances:
 At link init time, before regular polls are started.
 After the RTU indicates that it was reset.
 If report-by-exception reporting is disabled via
configuration (some RTUs apparently do not support
report-by-exception on analog inputs).
 At cyclic intervals (as specified in the configuration).
 After the disappearance of a status/alarm or an A/D
subsystem failure.
Yes 2 Accumulator scan. Used under the following circumstances

(after a accumulator freeze):
Yes 3 Status point scan. Used under the following circumstances:

 Whenever there is a COS queue overflow at the RTU.
subsystem failure.
Yes 4 Control select. Used only when a control request is received

from a master station.
Yes 5 Control execute. Used only as a follow-up to control
selections.
No 6 Not used.
Yes 7 Accumulator freeze. Used under the following circumstances
(after a clear status):
No 8 Accumulator reset (not used in the current implementation).

No 9 Accumulator freeze and reset (not used in the current
implementation).

Yes 10 Status point change (COS) dump. Used as part of the
normal polling cycle when no activity with a higher priority must
take place and a previous response has indicated that there is
at least one COS event available.
Yes 11 RTU status clear. Used under the following circumstances:
 Used whenever a non-NULL RTU status flag is received as
part of a response.
 At cyclic intervals (only for metering interval).
Yes 12 RTU configuration request. Used only as the very first

transaction at link initialization time.
Yes 13 Analog deadband download. Used only at link startup time
to download new analog deadbands for those points for which a
non-zero RTU deadband has been configured.
Yes 14 Analog change count request. Used as part of the regular
polling cycle when no response has been received indicating
that COS and analog exception events are available at the RTU.
Yes 15 Analog change (ABE) dump. Used as part of the normal
polling cycle when no activity with a higher priority must take
place and a previous response has indicated that there is at
least one analog exception event available.
Yes 16 - 19 Analog output select. Used only when a setpoint request has
been received from a master station for an output point that
has been configured as a select/execute point.
Yes 20 - 23 Analog output operate (used as a follow-up to a
select/execute setpoint operation).
Yes 24 - 27 Analog output direct control. Used when a setpoint request
has been received from a master station for an output point
that is configured as being a direct execute point.
No 28 Analog output scan. Used under the following circumstances:
subsystem failure.
No 29 SOE time sync: (not used in the current implementation).

No 30 Time-tagged COS queue dump. (not used in the current
implementation).
No 34 Pulse output (no reply) (not used in the current
implementation).
No 35 Pulse output (not used in the current implementation).

Yes 36 Sangamo BCD counter. Supported only with the Wesdac D20
RTU model.
Table 7-1 Protocol Requests
The following sections indicate the processing performed on data obtained from the RTUs.
7.1 RTU Status Flags

RTU status flags are received as part of every response sent by the RTU. The following RTU
status flags are received:
Flag name Associated Processing

Bit S7: Unused Unused
Bit S6: Unused Unused
Bit S5: Control Failure A control selection failure has occurred.
Bit S4: Hrdwr Malfunction A hardware malfunction has occurred.
Bit S3: Acc. Freeze/Reset Accumulators have been frozen and/or reset.
Bit S2: Bad RTU config The RTU configuration is questionable.
Bit S1: Bad Master Request The request received from the master request is
questionable.
Bit S0: RTU power cycled The RTU’s power has been cycled.
Table 7-2 RTU Status Flags
The processing associated with these status flags is minimal:

 The current state of each flag is maintained in the RTU statistics table. The contents of this
table can be viewed/reset at any time using standard SMP Tools.
 The count of positive transitions on each flag is maintained in the RTU statistics table.
 Individual flags are reset using the RTU Status Clear request, which in turn yields an
additional four bytes of detailed information, which is dependent on the type of RTU. These
32 bits of information are processed in the same way as the original 8 flags.
 If bits S5, S2 or S1 are set, then it is assumed that the response will only be four bytes long
(or five if CRCs are used rather than LRCs).
 If bit S0 is detected, the link is re-initialized from scratch. This means that new analog dead-
bands values are reloaded, and full state information is obtained for all I/O points.
7.2 COS and ABE Counts

COS counts are obtained as part of all RTU responses. The count is used to trigger a Status Point
Change Dump request at the earliest possible time, if required. A count of FF indicates that there
has been a COS queue overflow. This condition is logged in the statistics tables and results in a
complete Status Scan request at the earliest possible time.
ABE counts are obtained as part of responses to the Analog Change Count request. The count is
used to trigger an Analog Change Dump request at the earliest possible time, if required.

7.3 RTU Configuration
The RTU configuration is obtained as part of the RTU Configuration request issued at the start of
each link re-initialization sequence. For the time being, this information is stored in the RTU
statistics table. The contents of this table can be viewed at any time using standard SMP Tools.
The information also ensures that no polling occurs for points that are not being used.
7.4 Binary Inputs

Binary inputs are continuously scanned using the Status Point Scan or Status Point Change Dump
requests. All configured inputs are reported along with a status byte. Inputs that are not
configured are ignored. All transitions are time-tagged using the SMP Gateway current time,
unless the point is configured to use the RTU time-tag.
7.5 Analog Inputs

Analog inputs are straightforward. They are continuously scanned using either the Analog Scan
and/or Analog Change Dump requests. All configured inputs are reported along with a status
byte. Inputs that are not configured are ignored. All transitions are time-tagged using the
SMP Gateway current time.
7.6 Accumulator Registers

Accumulator registers are straightforward. They are continuously scanned using the Accumulator
Scan request. All configured registers are reported along with a status byte. Registers that are
not configured are ignored. All transitions are time-tagged using the SMP Gateway current time.
7.7 Analog Threshold Outputs

RTUs assign default threshold values to all analog inputs at RTU startup time. These threshold
values can be modified by the master station at a later date.
The VALMET TEJAS Series V master supports new threshold values supplied at system
configuration time. At each RTU/link reset, all non-zero threshold values are uploaded to the RTU
before regular scanning cycles begin. They cannot be changed dynamically afterwards.
This mechanism offers the advantage of allowing remote configuration of all threshold values
using standard SMP Tools.
7.8 Analog Outputs

RTUs support up to 64 analog output points using either a select before execute or a direct
execute paradigm.
Output processing is as follows:
 Control requests are issued by slave protocol components and are received by the VALMET
TEJAS Series V master protocol component in the form of standardized command messages.
 If the VALMET TEJAS Series V master is not in a state where setpoint commands can be
processed, the command is refused via an appropriate RTDX message. (RTU/Link down,
Initialization not finished, other selection already active, etc.).
 The VALMET TEJAS Series V master protocol component will accept select/execute
combinations or direct-execute requests from other protocol components. Hence, if
necessary, it is up to the master protocol component to translate select/execute
combinations into direct execute requests and vice versa.
 Depending on the command, a confirmation can be sent before (simulated) or after the
request has been forwarded to the end device (real). For any given output control operation,
only one confirmation is sent back to the initiator. For example, if a simulated confirmation is
requested for a EXECUTE command, the confirmation is sent only after all basic verifications
have been carried out. If the EXECUTE command is forwarded to the end device, the

VALMET TEJAS Series V master component will not send another confirmation to the initiator
once the operation is completed, whether it was successful or not. On the other hand, if a
real confirmation is requested for a EXECUTE command, the confirmation is sent back to the
initiator only once the end device has confirmed the operation or, if no response is received
from the RTU (unsuccessful confirmation), once the configured application layer response
timer has expired.
 The request was queued and picked up by the scan task at the next available opportunity. A
complete trace of all activities is maintained in the command log.
7.8.1 Interactions with the end device

The control requests that the VALMET TEJAS Series V master component transmits to the end
device depend on many factors, including the configuration of the output point and the operation
requested by the command initiator. The following table describes how each possible RTDX-
defined command is processed with respect to the initiator request and the output point
configuration settings. The description applies to analog output control requests and assumes
that the basic validation is successful in all cases.
Initiator request
Output point
configuration:
Direct Description of the processing
Simulated
Control Execute
confirmation
request
required
SELECT   A SELECT request is transmitted to the end
device. A confirmation is sent back to the
initiator when the end device confirms the
operation, or if no response is received, after
the application layer response timer expires. If
the operation is successful, the selection timer
is started.
  The output point is selected locally, i.e. no
request is sent to the end device. A
confirmation is sent back to the initiator and
the selection timer is started.
The VALMET TEJAS Series V master
component then waits for the associated
EXECUTE command before sending a DIRECT
EXECUTE request to the end device.
  The output point is selected locally, i.e. no
EXECUTE command before sending a SELECT
request to the end device, followed by an
EXECUTE request if the operation is completed
successfully.

Initiator request
Output point
configuration:
Simulated
Control Execute
confirmation
request
required
  The output point is selected locally, i.e. no

EXECUTE command before sending a DIRECT
EXECUTE request to the end device.
EXECUTE   If a SELECT request has already been sent to
the end device, only an EXECUTE request is
sent. Otherwise, a SELECT request is sent to
the end device, and if the operation is
completed successfully, an EXECUTE request
is sent.
In both cases, a confirmation is sent back to
the initiator once the operation has been
completed, whether it was successful or not.
  A DIRECT EXECUTE request is sent to the end
initiator once the operation has been
completed, whether it was successful or not.
  If a SELECT request has already been sent to
the end device, only an EXECUTE request is
sent. Otherwise, a SELECT request is sent to
the end device and, if the operation is
completed successfully, an EXECUTE request
is sent.
In both cases, a confirmation is sent back to
the initiator before any requests are sent to
the end device.
  A confirmation is sent back to the initiator and
a DIRECT EXECUTE request is sent.
DIRECT   A SELECT request is sent to the end device
EXECUTE and, if the operation is completed successfully,
an EXECUTE request is sent.
A confirmation is sent back to the initiator
once the operation has been completed,
whether or not it was successful.
  A DIRECT EXECUTE request is sent to the end
initiator once the operation has been
completed, whether or not it was successful.

Initiator request
Output point
configuration:
Simulated
Control Execute
confirmation
request
required
  A confirmation is sent back to the initiator. A

SELECT request is then sent to the end device
and if the operation is completed successfully,
an EXECUTE request is sent.
  A confirmation is sent back to the initiator and
then a DIRECT EXECUTE request is sent to the
end device.
Table 7-3 All possible interactions with the end device for analog output control requests
7.9 Control Outputs

RTUs support up to 256 control points using a Select before Execute control request.
Control requests are processed as follows:
 Control requests are issued by slave protocol components and are received by the VALMET
TEJAS Series V master protocol component in the form of standardized command messages.
 If the VALMET TEJAS Series V master is not in a state to process control requests, the
command is refused via an appropriate RTDX message (RTU/Link down, Initialization not
finished, other selection already active, etc.).
 The VALMET TEJAS Series V master protocol component will accept SELECT/EXECUTE
combinations or DIRECT EXECUTE requests from other protocol components. It is up to the
master protocol component to translate DIRECT EXECUTE requests to SELECT/EXECUTE
combinations.
 Depending on the control request, confirmations can be sent before (simulated) or after the
request is forwarded to the end device (real). For any given output control operation, a single
confirmation is sent back to the initiator. For example, if a simulated confirmation is
requested for a EXECUTE request, a confirmation is sent only after all basic verifications have
been made. If an EXECUTE request is forwarded to the end device, the VALMET TEJAS Series
V master component will not send another confirmation to the initiator once the operation
has been completed, whether it was successful or not. On the other hand, if a real
confirmation is requested for a EXECUTE command, a confirmation is sent back to the
initiator only when the end device confirms the operation or, if no response is received from
the RTU (unsuccessful confirmation), after the configured application layer response timer
has expired.
 The request was queued and picked up by the scan task at the next available opportunity. A
complete trace of all activities is maintained in the command log.
7.9.1 Interactions with the end device

The control requests that the VALMET TEJAS Series V master component transmits to the end
device depend on many factors, including the configuration of the output point and the operation
requested by the command initiator. The following table describes how each possible RTDX-
defined command is processed with respect to the initiator request and the output point
configuration settings. The description applies to binary output control requests and assumes
that the basic validation is successful in all cases.

Initiator request
Description of the processing

Simulated
Control
confirmation
request
required
SELECT  A SELECT request is transmitted to the end device. A
confirmation is sent back to the initiator once the end device
confirms the operation, or if no response is received, once
the application layer response timer has expired. If the end
device confirms that the operation was completed with
success, the selection timer is started.
 The output point is selected locally, i.e. no request is sent to
the end device. A confirmation is sent back to the initiator
and the selection timer is started.
The VALMET TEJAS Series V master component then waits
for the associated EXECUTE request before sending SELECT
request to the end device, followed by an EXECUTE request if
the operation is completed successfully.
EXECUTE  If a SELECT request has already been sent to the end device,
only an EXECUTE request is sent. Otherwise, a SELECT
request is sent to the end device and if the operation is
completed successfully, an EXECUTE request is sent.
In both cases, the confirmation is sent back to the initiator
once the operation has been completed, whether it was
successful or not.
 If a SELECT request has already been sent to the end device,
only an EXECUTE request is sent. Otherwise, a SELECT
request is sent to the end device and if the operation is
In both cases, the confirmation is sent back to the initiator
before any request is sent to the end device.
DIRECT  A SELECT request is sent to the end device and if the
EXECUTE operation is completed successfully, an EXECUTE request is
sent.
The confirmation is sent back to the initiator once the
operation has been completed, whether it was successful or
not.

Initiator request
Description of the processing

Simulated
Control
confirmation
request
required
 A confirmation is sent back to the initiator. A SELECT request

is then sent to the end device and if the operation is
Table 7-4 All possible interactions with the end device for binary output control requests
7.9.2 OPEN/CLOSE operations using two PULSE points

The VALMET TEJAS Series V master provides a mechanism whereby slave components can
operate two PULSE points using RTDX OPEN/CLOSE execute types. Two points are associated to
form an open/close pair. One handles open operations, the other close operations. Open/close
pair configuration is described in section 4.6.
An OPEN/CLOSE operation performed on any of these two points will result in a
PULSE control function being sent to the end device, on the point that handles the
requested operation. Note that even in this case, the PULSE execute type on either point of an
open/close pair is translated to a PULSE ON control function on the same point.

Valmet (Tejas Series V) Master Protocol: Reference Manual

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

Valmet (Tejas Series V) Master Protocol: Reference Manual

Uploaded by

Copyright:

Available Formats

Reference Manual

VALMET (TEJAS Series V)

Cooper Power Systems

Technical Support: PSSJ-support@cooperindustries.com

VALMET (TEJAS SERIES V) MASTER PROTOCOL REFERENCE MANUAL ●i

ii ● VALMET (TEJAS SERIES V) MASTER PROTOCOL REFERENCE MANUAL

VALMET (TEJAS SERIES V) MASTER PROTOCOL REFERENCE MANUAL ● iii

It is absolutely essential that you read and understand the above-mentioned

1.2 Document Overview

2 This chapter presents the component’s communication features and enumerates

VALMET (TEJAS SERIES V) MASTER PROTOCOL REFERENCE MANUAL ●1

Table 2-1 Communications Features

2.2 Implementation Restrictions and Warnings

2● VALMET (TEJAS SERIES V) MASTER PROTOCOL REFERENCE MANUAL

3.2 Binary information published via the RTDX

Status Bit Description

Table 3-1 Binary Input Status Bits

VALMET (TEJAS SERIES V) MASTER PROTOCOL REFERENCE MANUAL ●3

Normal (physical) binary inputs (type 0)

SMP Gateway-generated status bits (type 1)

RTU status bits (type 2)

Name Address Description

___CommFail 1.0.0.0 Communication with RTU is not active.

___RtuPowerRst 2.0.0.0 RTU status: Power recycled

4● VALMET (TEJAS SERIES V) MASTER PROTOCOL REFERENCE MANUAL

Table 3-2 Logical Binary Inputs

3.3 Analog information published via the RTDX

Status Bit Description

Communications Set to one when a correct reading/value cannot be obtained due to

Table 3-3 Analog Input Status Bits

VALMET (TEJAS SERIES V) MASTER PROTOCOL REFERENCE MANUAL ●5

Normal (physical) analog input reading (type 0)

SMP Gateway logical analog counters (type 1)

Metering analog counters (type 2)

Name Address Description

6● VALMET (TEJAS SERIES V) MASTER PROTOCOL REFERENCE MANUAL

Table 3-4 Logical Analog Inputs

3.4 Binary outputs controlled via the RTDX

Status Bit Description

Communications Set to one when a correct reading/value cannot be obtained due to

Table 3-5 Binary Output Status Bits

A binary output point can have one of the following states:

VALMET (TEJAS SERIES V) MASTER PROTOCOL REFERENCE MANUAL ●7

Table 3-6 Output Point States

Normal binary outputs (physical relays) (type 0)

8● VALMET (TEJAS SERIES V) MASTER PROTOCOL REFERENCE MANUAL

Name Address Description

VALMET (TEJAS SERIES V) MASTER PROTOCOL REFERENCE MANUAL ●9

Table 3-7 Logical Binary Outputs

3.5 Analog outputs controlled via the RTDX

10 ● VALMET (TEJAS SERIES V) MASTER PROTOCOL REFERENCE MANUAL

Normal (physical) analogs (physical relays) (type 0)

No other analog output types are currently supported.

3.6 Log Files

Log Entries made by the TEJAS Protocol Component

VALMET (TEJAS SERIES V) MASTER PROTOCOL REFERENCE MANUAL ● 11

Table 3-8 Log Files

3.7 Statuses and Statistics

Name Attributes Description

Instance Name Static Specifies the instance to which these

12 ● VALMET (TEJAS SERIES V) MASTER PROTOCOL REFERENCE MANUAL

Name Attributes Description

Instance name Static The instance to which these statistics