4CAE000545 - RTU500 Rel. 12.2 Engineer - Webinar

—
4CAE000545 V1.00, JAN 25 2018
RTU500 series
RTUtil500 Rel. 12.2.4 Engineering Webinar
Jacek Gronowski, PGGA-PT RTU Technical Support at http://abb.custhelp.com
RTU500 Geeks Group on ABB Yammer
—
Introduction
Presenter
Jacek Gronowski
RTU Technical Support line engineer
URL : http://abb.custhelp.com
Email : rtu-technical-support.deabb@de.abb.com
September 19, 2019 Slide 2

—
Introduction
GoToWebinar environment
Presentation, recording and Q&As will be shared with you after the webinar.
September 19, 2019 3

—
RTUtil500 Rel. 12.2.4 Engineering
Agenda
Introduction Communication
– General (1) – SNMP HCI Support with SNMPv2 and -v3 agent functionality (1)
– RTU500 Software release designation (2) – IEC 60870-5-104 BCI supports peer-to-peer communication (2)
– IEC 870-5-104 HCI. Support of IEC62351-3 (TLS 1.2) (3)
New functions – IEC 60870-5-104 SCI. IED polling sequence is configurable (4)
– Windows 10 Support (1) – IEC 60870-5-103 HCI. Generic Services support (5)
– Multiprog PRO (v5.5) Support (2) – IEC 61850 SCI/HCI. Support of Edition 2 (6)
– Command Control Authority Handling (3) – DNP3.0 (serial and LAN/WAN) HCI. Support of IEC62351-5 (7)
– HMI Server uniquely identifies every HMI client (4) – Modbus TCP/IP SCI. New parameters added (8)
– New 1-out-of-n control modes (5)
– Process image size and 'Transmitted'-flag in PLC (6) Others
Questions and Answers

—
Introduction
Slide 5
September 19, 2019
—
Introduction (1)
General
RTU500 Software Rel. 12.2 includes: All introduced changes have been documented in Release Notes
– Windows 10 Support, document of a given engineering tool::
– Support of new hardware modules, – Release note - RTU500 series version 12.2
– A number of new functions, – Release Note (Partner) - CMU Firmware Release 12
– Engineering improvements, – Release Note (Partner) - Software RTUtil500 Release 12
– Corrections of functional issues in RTU500 series related to cyber – Release Note (Partner) - Software Integrated HMI 2.0.2
security,
See as well other documents and presentations available on :RTU500
Partners Portal:
– Release of RTU500 version 12.2
– RTU500 Sales Webinar - Unveiling the potential of Release 12.2
– RTU500 series release 12.2 Sales webinar
– RTU500 Cyber Security Deployment Guideline Release 12

—
Introduction (2)
RTU500 Software release designation
RTU500 software release designation contains 4 parts: Before migration of old project to RTU500 Software Rel. 12.2 please
aa. bb = a major. minor release number read Migration Guide of RTU500 Release 12
cc = a build number
dd = for ABB internal use only if not equal to 0 Specifically note the following:
RTU500 software with the same major.minor release number part e.g. – Chapter 7. Migration of communication units.
12.2.1 and 12.2.2 share the same functional concept. It means that • Consider using 560CMR01 instead of 560CMR02 if you do not
they can be freely mixed - RTUtil500 Rel. 12.0.3 can be used with RTU need more than 2 serial communication interfaces.
firmware 12.0.7.
• Note that all new communication units use SD (Secure Digital)
New release of RTU500 software starts with a build number 1 e.g. instead of CF (Compact Flash) Cards. There is no way to migrate
12.2.1. Bugfix releases with corrected bugs are designated with an RTU Software license from CF to SD Card. It has to be
increasing build number. Higher build number means simply that purchased separately.
more bugs have been corrected without changing of RTU500
software functionality. – Chapter 9. Migration of Multiprog 2.11 projects to Multiprog 5.5.
Changing RTU500 firmware from 12.0.1 to 12.0.7 does not require
rebuilding of RTU500 configuration file with possibly newer RTUtil500
release. This is not considered as a migration.

—
New functions
Slide 8
September 19, 2019
—
New functions (1)
Windows 10 Support
All RTU500 engineering tools support now Windows 10 as well.

This includes:
– RTUtil500 Rel. 12.2 used for RTU project engineering.
– Multiprog Rel. 5.5 used for PLC programming.
– HMI Editor Rel. 2.0 used for HMI engineering.

—
New functions (2a)
Multiprog PRO (v5.5)
RTUtil500 Rel. 12.2 supports new engineering tool Multiprog 5 PRO Multiprog 5 introduces several important Improvements:
Multiprog 5 PRO is an IEC 61131 Control technology component of – Better Windows like user interface.
Phoenix Contact. – Library protection with Multiprog 5 function is now available.
Knowhow and Intellectual property (IP) of PLC logic can be protected
by the owner/developer.
– When starting Multiprog export RTUtil500 opens the target project in
Multiprog application and the I/O information is directly updated in
the project. No more explicit export/import is necessary.
– Export messages are logged to inform the user about the process.
– When exporting into an old Multiprog 2.11 project the project will be
migrated. Additional steps are described in the log messages.
RTUtil500 Rel. 12.0 supports Multiprog 2 only.
Hardlock key (Dongle) supports Multiprog 2.xx only. New software
license has to be purchased in order to support Multiprog 5. You
receive PDF file with Registration Code (33 characters long) per
workplace. Do not enter the License Number (14 characters) during
the product activation process.

—
New functions (2b)
Use always the newest Multiprog 5 setup file version: Note as well an updated Multiprog 2 setup file:
ABBRTU500PLCEngineering_1_0_1_0.exe MULTIPROG_wt_2_11_283-11_02.exe
Note the new name of Multiprog 5 PLC application: This version installs the newest (11.2) version of RTULIB/FW_LIB
libraries and support for new CMU modules (560CMR01, 560CMR02,
540CMD01 and 540CID01).
Please check your Multiprog 2 installation folder.
As a result the only valid entry which has to be used to uninstall this
software is (never use Multiprog wt):
: You cannot engineer PLC application for a new CMU hardware if
SH03_32 subfolder is not present.

—
New functions (2c)
Multiprog 5 uses RTULIB library to support RTU500 functionality of the PLC function blocks needed to support a new Command Control
corresponding firmware version. Authority function have been added to the new RTU500 firmware
In a current release RTU500Lib1 library project located in function block library FW_LIB.
c:\Users\Public\Documents\MULTIPROG\Libraries\ subfolder is It means that this FW_LIB library has to be updated in Multiprog 2
used. From functional point of view this project corresponds to RTULIB runtime as well. This has been included in the newest setup file
file Rel. 11.2 in Multiprog 2. MULTIPROG_wt_2_11_283-11_02.exe.
LIB_RELEASE POU is obsolete in Multiprog 5. To see version of Alternatively you can copy contents of the FW_LIB subfolder of
RTULIB used in a PLC project please use standard Multiprog 5 Multiprog 5:
functionality. Library version is available in properties (use right-click). - c:\ProgramData\PHOENIX CONTACT Software\MULTIPROG\5_51_257\plc\FW_LIB\
to the corresponding FW_LIB subfolder of Multiprog 2:

- c:\ABB\KWSoft211\MWT\PLC\FW_LIB\
Please make a backup of FW_LIB original contents in case

somethings goes wrong.

—
New functions (2d)
RTUtil500 12.2 with build number 1, 2 and 3 support Multiprog 5 only. Known issues:
Starting from RTUtil500 Rel. 12.2.4 both Multiprog 5 and Multiprog 2 – Multiprog 2 does not support Windows 10.
are supported and Multiprog 5 is set by default for a new project.
Multiprog version supported is a global project option selectable by a – Prerequisite for Multiprog 5 is an installed .NET framework 3.5.
user. Depending on the installation of the operating system, .NET
framework 3.5 may not be installed. This was especially noticed on
Windows 10 systems.
) – Multiprog 5 installer provided by ABB does not contain the .NET
framework installer. You have to install correct one manually or
computer has to be connected to the Internet during the installation
process.
– Evaluation license of Multiprog 5 has a restriction on the amount of
handled input and output data. Never use this evaluation license for
real projects executed on site.

—
New functions (3a)
Command Control Authority Handling
One side of every communication function in RTU500 is always Details have been described in Chapter 2.3.1 Configurable control
RTU500 Database. A new Command Control Authority function authority in RTU500 series Function Description Release 12 Part 6,
handles commands received by the RTU500 Database from HCI, RTU500 Functions
Integrated HMI or PLC.
This function allows to assign received process commands to a NCC 1 NCC 2
selected Control authority group identified by a unique number in
the range from 1 to 200. Value 0 means disabled state.

—
New functions (3b)
Command originators are identified for:

– Host interfaces (HCI, type=0) by the host number (1..16),
– Integrated HMI (type=1) by the HMI client number (1..16),
– PLCs (type=2) by the CMU number (1..16) the PLC is configured on.
By default all control operations of all Control Authority Groups are

allowed.
For a given Control Authority Group Logic or PLC function has the
task to control and signalize the Control Authority State of a specific
Command Originator.
Depending on this Control Authority State all commands of the
specified group and originator are allowed or rejected.
– PLC engineering is no more necessary.
– EXCEL import interface is supported.

—
New functions (3c)
Still you can use PLC to evaluate Command Authority of the selected – 'CTRL_AUTH_DENY_GET' function block gives the user the
command. Three new PLC function blocks have been added to the possibility to get, if commands assigned to a control authority group
RTU500 firmware function block library FW_LIB: are denied for an originator specified by originator type and
– 'CTRL_AUTH_DENY_SET' function block is intended to set for a identifier.
specific control originator a control denied state of a given Control – 'PLC_ICO_ADDR_GET' function block returns the 'intOriginator' of
Authority Group. It has four inputs: the running PLC function. Using this information, a PLC function can
• 'Group': selects the control authority group, as configured in identify, if command confirmations received by a PLC function are
RTUtil500. This is an USINT (IEC61131 type of integer). originated by itself.
• 'OriginatorType': is an enumeration which selects the originator
type HCI (=0), Integrated HMI (=1) and PLC (=2).
• 'OriginatorIdentifier' specifies the originator within an
originator type:
- 'Host Number‘ for HCI,
- 'HMI Client Number‘ for Integrated HMI,
- 'CMU number' for PLC (the CMU a PLC is located).
• 'Deny' sets the state for the previously selected control authority
group and originator.

—
New functions (4)
HMI Server uniquely identifies every HMI client
In previous RTUtil500 releases it was not mandatory to assign HMI To improve diagnostics and allow blocking of command with control
client numbers. authority of HMI clients not explicitly identified by their IP address, now
An HMI client number now uniquely identifies HMI clients even if they it is mandatory to assign HMI client numbers.
do not have a configured IP address. For signalization purposes, 8 more system events - SEV#261-276:
'HMI client x online' -were added.
When an HMI server is added to an Ethernet interface, an HMI client

with client number 1 is automatically configured. For HMI client
configuration of HMI server, IP address '0.0.0.0' is now allowed, which
is a wildcard for any connected HMI client.

—
New functions (5a)
New 1-out-of-n control modes
New process command Interlocking modes for commands executed Rel. 12.2.4:
by SCIs, IObus and PLC have been added.
Depending on the selection, commands are interlocked against each
other within groups or on an object level.
Technical details have been explained in Chapter 3.2.2 Command
output procedures of RTU500 series Function Description Release 12
Part 6, RTU500 Functions Previous releases:

—
New functions (5b)
Enhanced 1-out-of-n control (SCI, PDP and PLC)
New modes have been introduced: – Selection values '…with command priority' allow originators with
– Global: independent of the type only one command can be operated higher priority (e.g. HCIs with lower host number) to break a
at a time in RTU500. As long as a command is in operation (not yet selection of a '1-of-n-control group' by an originator of lower
completed or terminated by a time out) any further command priority. Still it is not possible to break execution of a command.
operation will be rejected.
– Configured:
Commands not assigned to any group by configuration are interlocked
on object basis only.
'1-out-of-n control group' parameters of For compatibility with older versions of RTU500 software the default
command data points are editable to setting is:
assign commands to a project specific '1-
of-n-control groups'.

—
New functions (6)
Process image size and 'Transmitted'-flag in PLC
It is possible to increase the RTU application latency where only the

current value of process data is relevant for a PLC application.
– Maximum amount of binary and measurement process information
entries in PLC queue are now separately configurable. Default value
is to keep up to 4 changes and the current value in the image.
– Behavior of ‘transmitted’-flag at AMI and MFI input variables can be
now configured.
• 'Edge‘: a rising edge informs about a new value. New changes
are available in the PLC program every second PLC cycle only
as an extra cycle is available for a falling edge.
• 'State‘: as long as the ‘transmitted’-flag is TRUE, a changed
value is available. In this case new changes are available every
PLC cycle.
Note that for outputs you can send out a new value still every second
task cycle.

—
Communication
Slide 21
September 19, 2019
—
Communication (1a)
SNMP HCI Support with SNMPv2 and -v3 agent functionality
SNMP HCI can be used to connect the RTU500 to the asset

management and/or TCP/IP net monitoring systems operating in
Network Monitoring
parallel to a SCADA system. System
It exposes RTU500´s system events as well as other diagnostic SNMP Trap SNMP Get/Respond
information (e.g. CPU and memory utilization, diagnostic counters).
SNMP v3 protocol defines a secure version of SNMP providing:

– Confidentiality (Encryption of packets)
– Integrity (Message Integrity)
– Authentication (verify source)
Graphical network analyze is possible via monitoring systems (AFS

View, MRTG, WhatsUp Gold, SUPROS…) as with SNMP you can Device Status Monitoring
collect data periodically or on event based method (TRAPS)

—
Communication (1b)
SNMP HCI Support with SNMPv2 and -v3 agent functionality
SNMP HCI agent has been described in a new RTU500 manual: For spontaneous reporting SNMP TRAPs can be enabled.
– SNMP Host Communication Interface
The agent provides a number of Object Identifiers (OIDs). An OID can
be thought as the “name of a variable".
The agent populates values of variables and makes them available. An
SNMP manager (client) can then query the agent’s OIDs for a specific
information.
The collection of all the objects of an SNMP agent makes up the MIB
(Management Information Base), which can be described according
to the standard in a text file:
– ABB RTU500 MIB file for SNMP Host Communication Interface

—
Communication (2a)
IEC 60870-5-104 BCI supports peer-to-peer communication.
A new activity type - Bi-directional communication interface (BCI) The visualized parent child relationship presentation in RTUtil500
has been added to RTU500 software to support bi-directional (peer-to- network tree does not reflect the communication relationship between
peer) communication lines. devices connected to a bi-directional topology.
Bi-directional activity means that subordinated as well as super

ordinated devices (RTUs, IEDs) on such line can contain data points
and these data points can be exchanged in both directions
In fact all linked devices are functionally on the same level.
between all devices connected to the same bi-directional
communication topology using own pair of links. Any device can be selected as a root node in order to support
traditional engineering tools.
Every Bi-directional communication interface (BCI) can play the
role of:
– a data point producing device, like IEDs,
– a data point consuming device, like control systems.

—
Communication (2b)
Bi-directional communication interface (BCI) in RTU500 has been The following functions supported in IEC 60870-5-104 (HCI) are not
implemented on top of IEC 60870-5-104 specification. Not all aspects available in bidirectional communication interface (BCI):
of the current IEC 60870-5-104 SCI/HCI functionality have been Structured addresses for ASDU and IOA.
included. – The configuration of control systems as communication partner (for
The following functions supported in IEC 60870-5-104 (SCI) are not the BCI external device are configured as IED).
available in bidirectional communication interface (BCI): – Simultaneous communication with up to 8 hosts (Multi-Host
connection).
– Structured addresses for ASDU and IOA. – Configuration and exclusive connection to host IP addresses. (BCI
– Read commands (C_RD), reset process command (C_RP) and test supports redundant connections with 2 links).
command (C_TS). – Counter interrogation commands (C_CI) and counter modes B, C, D.
– File transfer. – Read commands (C_RD), reset process command (C_RP) and test
command (C_TS).
– Parameter download and file transfer.
– Supervision of maximum delay in command direction of commands
and setpoints.

—
Communication (2c)
Monitoring direction Command direction

All Event/Measurement information from one device could be available Commands can be executed from every device to any other device
at all linked devices without sending them to a control system and back linked to the same bi-directional topology.
to another device. Note that any linked device can have independent
SCI, HCI in order to acquire and/or distribute available process data to
control systems.

—
Communication (2d)
A device can be linked to a bi-directional topology as an IED node or Every device linked to a bi-directional topology is addressed using
RTU500 node. unique IP Address.
– RTU500 node is fully engineered (communication and data) in the
same RTUtil500 project as the root node.
– IED node is engineered externally (can be another RTUtil500 project
or device of any type or vendor)
Redundant communication (second IP address) is supported.

TCP port used for a communication can be configured when required.
This can simplify firewall configuration.
Note that every device linked to a bi-directional topology creates a
separate pair of Sub/Host like communication interface with every other
device connected to the same topology.

—
Communication (2e)
In case of RTU500 node device IP address has to the same as IP

address of E1 or E2 port of CMU where engineered BCI is linked.
No other IP addresses are allowed.

—
Communication (2f)
All devices linked to a bi-directional topology share the same process For RTU500 Node configuration of selected Host activity parameters
data database. As a result Information Object Address (IOA) of any is possible similarly as in a standard HCI.
process data must not overlap with IOA of any other process data
located on the other device connected to the same bi-directional
topology. Any shared process data is available on any device
connected to engineered bi-directional topology.
For IED Node there is no way to configure Host activity parameters

as this is engineered in an external project.

—
Communication (3)
IEC 870-5-104 HCI. Support of IEC62351-3 (TLS 1.2)
Only available with license feature "Advanced security". Configuration of secure IEC 60870-5-104 HCI needs extra 2
Data traffic will be secured by Transport Layer Security (TLS) parameters only: Securing data traffic and Certificate selection.
encryption and authentication by means of X.509 certificates.
IEC 62351-3 provide end-to-end encryption between RTU500 and
Network control centers. Provide protection against (secured by):
– Eavesdropping (TLS encryption)
– Man-in-the-middle attacks (message authentication)
– IP spoofing (Certificates)
– Replay attacks (TLS encryption)
RTU500 provides now the separate TCP/IP port 19998 to exchange
TLS secured traffic. This will allow for the possibility of unambiguous
secure and non-secure communications simultaneously.

—
Communication (4)
IEC 60870-5-104 SCI. IED polling sequence is configurable
In a setup with both Ethernet interfaces on the same subnet a new

dropdown list 'Routing' is available with two options:
– Static assignment of IP addresses (E1 -> IP1, E2 ->IP2), behavior
as before.
– Dynamic usage of configured network interfaces. IP addresses 1
and 2 of the IED are polled on both interfaces sequential.

—
Communication (5)
IEC 60870-5-103 HCI. Generic Services support
Generic data (type identification 10) is supported now for the

following RTU data types:
– in control direction : ASO, FSO, BSO01, BSO02, BSO08, BSO16
– in monitoring direction : AMI, MFI, STI, BSI08, BSI16, BSI32.
This allows e.g. to support TAPCON devices.
The following GDD data types (Generic Data Description) are
supported by RTU500:
– <4> signed integer
– <7> R32.23 Short real IEEE754
General interrogation of generic data (GGI) is also supported.
For more detailed information see protocol documentation IEC 60870-
5-103 Subdevice Communication Interface

—
Communication (6a)
IEC 61850 SCI/HCI. Support of Edition 2
The RTU500 series IEC 61850 client and server supports Edition 1 Mixed systems (the SCD file is Edition 2 including Edition 1 data
(IEC 61850-7-x:2003A) and Edition 2 (IEC 61850-7-x:2007B) of the models) are supported for client/server communication. There is one
standard. SCD file only for mixed systems. See Chapter 26.3 Mixed Systems,
The following restrictions apply: Engineering in IET600 Integrated Engineering Tool User Manual for
– Only one type of protocol Edition can be started on one CMU. more details.
– During engineering put IEDs of different Editions into different Mixed systems are not part of SVC system tests (not verified)
Subnetworks (requires a separate CMU). anymore.
– No RCBs can be exchanged between Edition 1 and Edition 2
IEDs.
– The GOOSE communication in RTU500 series is restricted to IEDs
of the same edition. The configuration tool RTUtil500 checks this
restriction and GOOSE data points from IEDs with the wrong edition
are ignored (Presenting a warning message for the user).
– For extensions of existing Edition 1 systems (Edition 1 SCD) the
RTU500 series must be configured as Edition 1 IED.
– The extension of Edition 1 system with Edition 2 devices is not
supported.

—
Communication (6b)
IEC 61850 SCI/HCI. Support of Edition 2
Protocol Edition has to be defined separately for any client or Key features:
server interface in the RTU500 project. – Higher RTU System Limits documented in RTU500 series
Function Description (Parts 2 and 3, Chapter: System Limits).
– PRP redundancy is supported both for the client and the server. The
supervision of the channel status can be engineered with GGIO’s for
the server. The client’s redundant channels can only be supervised
from the NCC.
Due to the differences in the data model between Edition 1 and – RTU500 does not support HSR. You have to use an external
Edition 2 the selected protocol edition of communication interface switch/bridge/router if you need to connect RTU to such network.
cannot be changed anymore after an SCD import was done or after
any data points are configured for the client or server.
Change of selected Protocol Edition requires the complete repetition
of IEC 61850 Integration procedure.

—
Communication (7a)
DNP3.0 (serial and LAN/WAN) HCI. Support of IEC62351-5
Only available with license feature "Advanced security". Key features:

DNP3 with secure authentication (SA) based on IEC62351-5 has – Session Key exchange with AES128 and AES256.
been implemented as an extension. – Request authentication with HMAC of SHA1 and SHA256.
It enables secure communication (serial and LAN/WAN) with – Aggressive mode can be configured
connected SCADA systems (NCC/DMS, tested with MicroSCADA
Pro). – Protocol extension of handling new function codes when SA is
enabled.
This is an Application Layer (on ASDU level) extension only. DNP3
Secure Authentication does not provide complete encryption of – Implementation of set of function codes that are protected by SA.
transported data. Traffic is still vulnerable for sniffing. – Handling of new DNP3 objects g120v1 to g120v7 and g120v9.
– Object g121v1 – Security statistics was implemented

—
Communication (7b)
DNP3.0 (serial and LAN/WAN) HCI. Support of IEC62351-5
Feature can be configured in RTUtil500 in line configurator window. With Secure Authentication enabled RTU keeps track of events like
unsuccessful Session Keys exchange.
Increased number of these events may indicate that RTU is
misconfigured and master with different Update Key is trying to connect
or that outstation may be under attack.
All events are available under group 120. They are also returned in
Class 0 request if Secure Authentication is enabled. Several of different
events may be logged.
More details about the implemented functionality, like a full list of

implemented critical request function codes, can be found in:
DNP3.0 Host Communication Interface

—
Communication (8)
Modbus TCP/IP SCI. New parameters added
– New checkbox option: ‘Allow only one query simultaneously’. – New settings value 30ms is now supported for 'Cycle time for line
By default the functionality is deactivated for compatibility with older 1' and 'Cycle time for line 2‘
RTUtil500 Releases. Be aware that using low values for cycle time may reduce overall
If the option is checked RTU sends the Modbus TCP queries in such system performance.
order, that no new query is sent before the previous one is not
completed (responded or timed out). This option is required for
some simple Modbus TCP/IP to Modbus serial converters which do not
handle frame buffering correctly.

—
Others
Slide 38
September 19, 2019
—
Others (1)
Changed RTUtil500 operation
– Default location of RTUtil500 data folder has been modified. Now – SEVs are no longer automatically added to the SDI node
ABB\ has been inserted. In older releases in a new project, a lot of unwanted system events
have been automatically added to the System Data Interface (SDI)
node. This is not done anymore.
The firmware ensures at startup that all needed SEVs are created if
they are not configured in RTUtil500.
Never add SEV #48 (Device inoperable) to SDI of the configured

RTU. This SEV has to be always evaluated by a host/client as it is
Uncheck “Link functionalities to all network interfaces…” to follow never sent by HCI.
Cyber Security rules. Typically operation of a configured function is
expected on one dedicated communication interface.

—
Others (2) / New functions
Support of new hardware modules
The following hardware modules have been introduced with RTU500 RTUtil500 Rel. 12.2.4 supports directly all new hardware modules.
Rel. 12.x: 560BIR01, 560BOR01 and 560AIR01 are 100% function and pin
– 560CMR01, 560CMR02 compatible with corresponding 23BE23, 23BA20 and 23AE23.
– 560BIR01, 560BOR01, 560AIR01, 560AIR02 They can be freely used as a spare part of old (phase-out) module
– 540CMD01, 540CID01 without any RTUtil500 re-engineering. It means that you can configure
in your RTU project old modules but in fact you can mount new ones.
– 520CSD01
560AIR02 is a cost optimized mA solution without any jumper or dip
They are more flexible, consume much less power. switches. This is a new card supported by RTUtil500 Rel. 12.2 or
newer.
Note new RTU System Limits presented in:
– RTU500 series Function Description Release 12 Part 2, Rack
Mounted Solutions
– RTU500 series Function Description Release 12 Part 3, DIN Rail
Solutions

—
Others (3) / New functions
New parameter: 'Command operation timeout'
The maximum time until a started command operation procedure is

released, in case it was not completed before, can be customized with
the introduced parameter.
This prevents long blocking of subsequent commands execution in
RTU.

—
Others (4) / Communication
IEC 61850 SCI. Scaling of acquired measurements.
New parameter Multiplier is now available for incoming MFI data point
which allows to rescale the RTU internal representation of received
measurement.
The multiplier scaling is executed at the incoming value, before
threshold supervision check if this is configured.
Always configure threshold supervision check for incoming analog
data. This always decreases the load of CMU.

—
IEC 60870-5-101/104 HCI. New parameters added
– New background cycle time interval 15 minutes has been introduced – New configuration option to disable parameter loading per HCI has
for AMIs and MFIs. been added. In older releases of RTUtil500 parameter loading is
enabled per default.
Deviating from standard in RTU500 the IOA (Information Object

Address) used to carry information in control and monitor direction are
the same for the parameter types. As specified in IEC 60870-5-101
clause 7.2.5, this is not allowed and the return information should be
This allows better support data used in trend reports.
addressed by a different IOA.
To achieve conformity with standard in RTUtil500 there is now a new
configuration option to disable parameter loading per HCI at all. If
parameter loading is disabled, requests will be responded with
negative activation confirmation.
That applies for the following type identifications: P_ME_NA_1,
P_ME_NB_1, P_ME_NC_1.

—
IEC 60870-5-101 HCI. Redundancy switchover condition
An additional parameter 'redundancy switch over condition' has

been added for IEC 60870 5-101 protocol. This parameter defines how
the switchover of the controlling station is done:
– According to IEC standard (Norwegian user convention) RTU500
switches to redundant line upon 'reset of remote link' (FC0)
command (default state for older RTU software releases),
– The switchover to redundant line should be done by 'request of
user data' command. (FC11). Precondition: Redundant lines and
transmission mode unbalanced.
This scheme is used in Company PSI (Germany/Malaysia) controlling
systems.

—
Questions and Answers
Slide 45
September 19, 2019
—
Questions & Answeres (1)
# Slide Question Answer

1 10, 11 Do you see any option to work with Hardlock key (Dongle) supports Multiprog 2.xx only. Multiprog 2 does not support Windows 10. You
Windows 10 laptop and with the can use Virtual Machines running Win7 as a workaround.
Multiprog WT Hardlock key (Dongle)? See related thread on our RTU500 geeks Group.
2 10 How Multiprog 5 is licensed. New software license has to be purchased in order to support Multiprog 5. You receive PDF file with
Registration Code (33 characters long) per workplace.
Multiprog 5 software requires Registration Code for every location (workplace) where this software
has been installed. You have to remove Multiprog 5 software from an old computer before registration
with the same Registration Code on a new computer.
Note that we are reselling only licensees purchased from Phoenix Contact. They can explain you any
legal details related to this topic.
3 10 Does Multiprog 5 support symbolic Yes, it does. This is even easier than in Multiprog 2.
variables. See Step by step guide for PLC programming using Multiprog 5
4 11 Can you explain a note about usage of See Chapter 8, 9 in Migration Guide of RTU500 Release 12. New CMU types require new PLC resource
new CMUs in Multiprog 2.11 type (SH03_32). This is created automatically after the first Import in Multiprog 2.
5 12 How is Multiprog 5 RTULib identified See added slide 12 for an explanation.

—
Questions & Answeres (2)
# Slide Question Answer

6 22 Do we need separate firmware for SNMP No, according to our licensing policy all communication protocols are included in a Basic License.
HCI?
7 27 Is it mandatory to configure all RTU500 No, this is not mandatory and even sometimes not possible. Note that IED Node is engineered
devices and other IEDs in one RTUtil500 externally (in a different project). It can be a device of another type than RTU500, engineered using
project? different tool than RTUtil500.
In the current RTUtil500 release there is no consistency check that every Information Object Address
(IOA) is unique in the engineered bi-directional topology even in case all nodes are RTU500 nodes
engineered in the same RTUtil500 project.
8 30, 35 How to order "Advanced security“ "Advanced security“ feature needs to be separately specified (1KGT036600R0001) in the order of the
feature? specific SD/CF license. This is required for Secure IEC 870-5-104 and DNP3.0 communication,
9 34 How many IEDs are supported by IEC For new CMUs we have raised the limit to 30 IEDs per IEC 61850 client.
61850 client? See System Limits chapter in:
- RTU500 series Function Description Release 12 Part 2, Rack Mounted Solutions
- RTU500 series Function Description Release 12 Part 3, DIN Rail Solutions
10 Why it is not possible to issue This has been moved in RTU Software Rel. 12.0 to Test Mode option. See Chapter 4.4.4 in Web-Server
commands in Hardware Tree in RTU Users Guide, Release 12 for a description how to simulate commands in RTU.
Web Server

4CAE000545 - RTU500 Rel. 12.2 Engineer - Webinar

Uploaded by

Copyright:

Available Formats

4CAE000545 - RTU500 Rel. 12.2 Engineer - Webinar

Uploaded by

Document Information

Original Description:

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

4CAE000545 - RTU500 Rel. 12.2 Engineer - Webinar

Uploaded by

Copyright:

Available Formats

—

4CAE000545 V1.00, JAN 25 2018

September 19, 2019 Slide 2

September 19, 2019 3

September 19, 2019 Slide 4

– A number of new functions, – Release Note (Partner) - CMU Firmware Release 12

– Engineering improvements, – Release Note (Partner) - Software RTUtil500 Release 12

September 19, 2019 Slide 6

September 19, 2019 Slide 7

All RTU500 engineering tools support now Windows 10 as well.

September 19, 2019 Slide 9

September 19, 2019 Slide 10

September 19, 2019 Slide 11

to the corresponding FW_LIB subfolder of Multiprog 2:

Please make a backup of FW_LIB original contents in case

September 19, 2019 Slide 12

September 19, 2019 Slide 13

September 19, 2019 Slide 14

Command originators are identified for:

By default all control operations of all Control Authority Groups are

September 19, 2019 Slide 15

September 19, 2019 Slide 16

When an HMI server is added to an Ethernet interface, an HMI client

September 19, 2019 Slide 17

September 19, 2019 Slide 18

September 19, 2019 Slide 19

It is possible to increase the RTU application latency where only the

September 19, 2019 Slide 20

SNMP HCI can be used to connect the RTU500 to the asset

SNMP v3 protocol defines a secure version of SNMP providing:

Graphical network analyze is possible via monitoring systems (AFS

collect data periodically or on event based method (TRAPS)

September 19, 2019 Slide 22

September 19, 2019 Slide 23

Bi-directional activity means that subordinated as well as super

September 19, 2019 Slide 24

September 19, 2019 Slide 25

Monitoring direction Command direction

September 19, 2019 Slide 26

Redundant communication (second IP address) is supported.

September 19, 2019 Slide 27

In case of RTU500 node device IP address has to the same as IP

September 19, 2019 Slide 28

For IED Node there is no way to configure Host activity parameters

September 19, 2019 Slide 29

September 19, 2019 Slide 30

In a setup with both Ethernet interfaces on the same subnet a new

September 19, 2019 Slide 31

Generic data (type identification 10) is supported now for the

September 19, 2019 Slide 32

September 19, 2019 Slide 33

September 19, 2019 Slide 34

Only available with license feature "Advanced security". Key features:

September 19, 2019 Slide 35

More details about the implemented functionality, like a full list of

September 19, 2019 Slide 36

September 19, 2019 Slide 37

Never add SEV #48 (Device inoperable) to SDI of the configured