Beruflich Dokumente
Kultur Dokumente
Revision
Document identity: 1KGT 150 924 V001 1
Revision: Date: Changes:
0 07/2016 New document for Release 12.0
1 07/2016 Update: Chapter 'Opening the user interface' (PR#33042)
08/2017 Update: Chapter 'Diagnostics, Hardware tree, General
Overview' (PR#33036)
Contents
1 Introduction.................................................................................................................... 1-1
1.1 Preface................................................................................................................1-1
1.2 Structure of this document................................................................................. 1-1
1.3 References.......................................................................................................... 1-1
1.4 Access to the Web server.................................................................................. 1-2
1.5 Presentation of the RTU500 series Web Pages.................................................. 1-4
2 Management.................................................................................................................. 2-1
2.1 Configuration Management................................................................................. 2-1
2.2 Firmware Management....................................................................................... 2-2
2.3 License Management..........................................................................................2-4
2.4 Language Management...................................................................................... 2-5
2.4.1 Change language of the Web server..................................................2-6
2.5 User Management.............................................................................................. 2-7
2.5.1 Security Policies.................................................................................2-8
2.5.2 User Accounts / Passwords.............................................................2-10
2.5.3 User Roles....................................................................................... 2-12
2.5.4 Change own user password............................................................ 2-14
2.5.5 Password file management..............................................................2-15
2.5.6 Password file harmonization.............................................................2-16
2.6 Certificate Management.................................................................................... 2-19
2.7 System Help Page with pre-requisitions............................................................2-19
3 Diagnostics.....................................................................................................................3-1
3.1 System Log........................................................................................................ 3-1
3.2 System Event Status.......................................................................................... 3-2
3.3 Hardware Tree.................................................................................................... 3-3
3.3.1 General Overview...............................................................................3-3
3.3.2 Board Diagnosis.................................................................................3-4
5 Operation....................................................................................................................... 5-1
5.1 Starting the Integrated HMI.................................................................................5-1
5.2 General Overview: Archives................................................................................ 5-1
5.3 Process Archives................................................................................................ 5-2
5.4 File Archive......................................................................................................... 5-3
5.5 Security Event Archive........................................................................................ 5-4
6 Engineering.....................................................................................................................6-1
6.1 Use case 1: Pre-configured RTU520.................................................................. 6-1
6.2 Use case 2: RTU520 online configuration........................................................... 6-2
10 Glossary....................................................................................................................... 10-1
1 Introduction
1.1 Preface
The document describes the requirements and installation steps needed to build up a full RTU500
series engineering environment. The base configuration of the Microsoft Windows Operating System
and the tools required for the engineering process are described. System requirement are defined
in chapter Chapter 2.7 in figure "Fig. 28: Page for general information and pre-requisitions" .
The first part describes the RTU500 series Web server functionality:
The first part describes the RTU500 series Web server functionality:
• Management functions:
– Configuration management
– Firmware management
– User management
– Loading of password files
– Help page
• Diagnosis functions
– System logs
– Process diagnosis functionality (Hardware Tree)
– The Network Tree
• Operation functions
– Starting the Integrated HMI
– File archive functions
• Engineering
– Changing individual parameters online
– Onlne generation of a new RTU configuration
The second part includes the installation and configuration of the environment.
• PPP Installation
• USB Installation
• Establishing the connection
• Network configuration
• The hardware required for the connection
1.3 References
Additional Information is available in the documents:
The access to the RTU500 series Web server is enabled by default, but it is possible to disable the
access for each Ethernet interface in the configuration tool RTUtil500 [2]. See chapter "RTUtil500
configuration" for information how to disable the RTU500 series Web server.
Besides the secure standard HTTPS access, the RTU500 series Web server supports also HTTP.
For more information about the secure access see chapter 7-1. This chapter describes the
configuration and the certificate handling required for the secure HTTPS access.
After a successful connection, the RTU500 series Web server requests a user name and password
for log-in. An example for the log-in dialog presented by the Web browser is shown in the figure
below. Information about the default user names and passwords can be found in chapter "User
Accounts / Passwords".
After completing the working session it is recommended to log-off from the RTU500 series Web
server and to close the used Web browser. This prevents the usage of supplied user names and
passwords by unauthorized persons. The log-off is done by selecting the link "Logout" as shown in
the figure below. The appearing dialog must be confirmed with Ok to execute the log-off.
Additional to the manual log-off, the user will be logged off by the RTU500 series after a configurable
time of inactivity. The timeout for automatic logout after user inactivity could be disabled and is
configurable between 1 minute and 24 hours. In RTUtil500 the inactivity timeout parameter is placed
in the "Parameter" tap at an RTU (Network or Hardware tree). The figure below shows the according
RTUtil500 parameter user interface.
When using the Microsoft Internet Explorer as Web browser the advanced option "Show friendly
HTTP error messages" shall be disabled in the Internet Explorer. Without this option the detailed
error information of the RTU500 series Web server are not shown. The option can be found in the
"Advanced" tab of the "Internet Options" (see figure below).
The 'status frame' (1) is fixed during runtime, but depending on the configuration of the RTU.
The navigation tiles (2) is fixed during runtime and used to navigate through the different Web server
functions.
The 'presentation frame' (3 left side) depends also on the configuration of the RTU, but will not be
updated, as long as the frame is shown.
2 Management
2.1 Configuration Management
To navigate to the Configuration-File Manager page, click on "Management" and on "Configurations
Management" in the navigation frame. The different table columns show the properties of the dif-
ferent files.
The files on the RTU will be displayed on top of this page. Below is the drop in area. Here you can drop
new configuration files to be downloaded to the RTU. Only one file is needed for the configuration
of an RTU: <name>.rcd (RTU configuration data)
In addition the Integrated HMI project files can be downloaded with this page.
The different table columns show the properties of the different configuration files.
With this button the configuration file can be downloaded to the RTU. First the config-
uration file must be dropped into the drop file area. Then the file can be downloaded
to the RTU. The downloaded file will become the new base configuration file. It must
be activated in a next step.
Send file to device
With this button the configuration file on the RTU can be uploaded to the PC.
Delete file
By selecting this button the base or backup configuration will become the new active
configuration.
Activate configuration
Press this button in the active configuration row to generate a new backup of the ac-
tive configuration. The new backup configuration will override an existing backup con-
figuration.
Backup configuration
Table 1: Configuration Management: Operation buttons on the left side of the tables
The files on the RTU will be displayed on top of this page. Below is the drop in area. Here you can
drop new firmware files to be downloaded to the RTU.
The loading of the different software files is independent. The software is not distributed to other
boards while loading.
With this button the firmware file can be downloaded to the RTU. First
the firmware file must be dropped into the drop file area. Than the file can
be downloaded to the RTU. The downloaded file will replace the existing
Send file to device firmware file on the flash. It must be activated in a next step. After a suc-
cess full download a red exclamation mark will appear and the activate
botton will become visible.
With this button the firmware file on the RTU can be uploaded to the PC.
Delete file
By selecting this button the firmware file will be activated and the RTU will be restart-
ed.
Activate
This sign indicated a difference between the firmware file on the flash and the firmware
under operation for the the RTU. The activation of the firmware is required.
Table 2: Firmware Management: Operation buttons on the left side of the tables
ADVICE
On the RTU there is no backup of the firmware files available. Deletes files must be replaced by
files from the PC.
It is possible to upgrade the RTU license with an license extension file (ABBRTU500Ext.lic), generated
by ABB, by uploading the file via the Web server.
The data of the license file is checked during loading the file. The new licenses are activated after
a reset.
For each language 2 language files are required. For example for english langage:
– webserver_en-US.stb (CSV format)
– RTUi_en-US.rdt (XML format)
With this button the language file can be downloaded to the RTU. First the language
file must be dropped into the drop file area. Than the file can be downloaded to the
RTU.
With this button the language file on the RTU can be uploaded to the PC.
Delete file
By selecting this button the language will become the new active language. A reboot
of the RTU is required.
Activate
Table 3: Language Management: Operation buttons on the left side of the tables
ADVICE
The web pages of this functionality require secure HTTPS access. It is not possible to open the
web pages with standard HTTP access.
The user interface for the account management consists of several menu tabs. The first 3 menu tabs
cover the password policies, the user accounts and the user roles. On each tab the corresponding
information are shown for display and modification.
Common for all menu tabs are 2 buttons at the top of each tab. These buttons control the changes
done by the administrator. At startup all control elements are disabled showing the current config-
uration. If changes shall be done the administrator just start to access the user interface. Then the
both control buttons get active. After finishing the administrator can accept and store the changes
by pressing the button "Save" or returning to the former configuration by declining the changes with
the button "Cancel". It is irrelevant on which tab the control buttons are used. The change process
could be started or finished on each tab.
ADVICE
Be sure to save any wanted modification in the user account management by pressing the "Save"
button.
When the changes are accepted an additional dialog appears to confirm the decision. The changed
account configuration is active right after accepting the changes. There is no need to reset the RTU
but all users are logged out and a re-login is required. During accepting the changes are distributed
within the RTU CMU's which could take a few seconds.
To avoid conflicts no access is possible via the Web server when an administrator has started the
account change process. This compromises the access from other CMU's as well. The next chap-
ters describe each menu tab in detail.
• Functional policies that define restrictions in the access to the RTU500 series and
• Password policies that define rules that a password must fulfill to get accepted.
The following sections describes the functional and password policies in detail.
Functional policies
The functional policies define restrictions in the access to the RTU500 series. When activated certain
functionalities are disabled and cannot be used anymore. The following functional policies can be
activated for the whole system:
See part (1) of the Web server screen shoot "Fig. 16: Menu tab security policies" for the password
policies user interface.
Password policies
The password policies define rules that a password must fulfill to get accepted by the RTU500 series.
To enable the password policies the check box "Enforce password policies" must be checked (see
figure in last chapter). Changes in the password policies are considered for new passwords only.
That means existing passwords are not checked against the policies and the passwords are still
valid and usable. To be sure that all passwords are compliant the passwords must be changed after
defining a password policy.
After enabling the password policies the control elements are enabled and changes could be done.
The following parameters are editable:
• Minimum length of a password. The required length of a password could be set to 0 which
means no required length or to a value between 6 and 31. In case of 0 the password must be
at least 3 characters long (see implicit rules below).
• Maximum lifetime of a password. This parameter defines the time after a password became
invalid and could not be used anymore. The time is configured in days with a range from 0 to
1000. The value 0 means that the password never became invalid.
• Contains lower case characters. If this check box is set the passwords must contains at least
one lower case character.
• Contains upper case characters. If this check box is set the passwords must contains at least
one upper case character.
• Contains numeric characters. If this check box is set the passwords must contains at least one
numeric character '0' to '9'.
• Contains special characters. If this check box is set the passwords must contains at least one
of the listed special character:
" [!£$%^&*@?<>+_]\"
Even when the password policies are not enabled there are certain rules for passwords. These are
minimal rules to ensure proper system functionality. These implicit rules are:
Independent from the password policies there are as well implicit rules for user names. These rules
are:
See part (2) of the Web server screen shoot "Fig. 16: Menu tab security policies" for the password
policies user interface.
On the right side of the table are the assigments of the user roles. One or several roles can be
assigned to an user account. The user role can be assigned or withdrawn by selecting the corre-
sponding checkbox at the user account. The specific permissions assigned to a user role are defined
in the menu tab "User Roles" described in the next chapter.
At the end of the table of existing user accounts there is an empty field for adding a new user. A
new user account is created by typing a user name and pressing <ENTER>. Then a dialog appears
to set the initial password of the new user account (as shown in the next figure). By confirming the
dialog with "Ok" the user account is created. For information about rules that must be consider when
choosing a user name or password see chapter about the password policies.
When changing a user password the same dialog appears as when setting the initial password.
In the dialog the affected user name is displayed and 2 text fields to type the new password. The
password must be typed two times to eliminate, unintentional typing errors. The new password is
accepted only if both text fields contain the same password.
The new password is checked against the policies rules when the button "OK" is selected. In case
of violations the password is declined, an error message is shown and a valid password must be
defined. The dialog can be finished by pressing the button "Cancel". In this case the password is
not changed and the old password is still valid.
In delivery status the RTU500 series contains the following predefined user accounts, with their
assigned user roles and their defined default user role:
During migration from the previous RTU560 user account management (before release 12) the ex-
isting user accounts are taken as they are. That means user names, passwords and role assign-
ments remains unchanged after the migration.
ADVICE
The predefined superuser Default is added to the user accounts during migration from the pre-
vious RTU560 user account management. So, if the user accounts are defined individual be sure
to remove the superuser after the migration.
On the right side of the table are the specific permissions assigned to a user role. A permission can
be assigned or withdrawn by selecting the corresponding checkbox at the user role.
There is an empty field at the end of the table of existing roles for adding a new user role. A new
user role is created by typing a role name and pressing <ENTER>. There are the following rules
defined for role names:
The account permissions available in the RTU500 series are fix defined and cannot be changed.
Each defined account permission allows several actions within the RTU500 series Web server or
Integrated HMI. The table below shows all available permissions and describes the allowed actions
for every permission in detail.
To reset the password file to factory default the button "Reset" has to be used. When pressed a
dialog appears to confirm the reset. After confirmation with "Ok" the default password file is active
directly. A reset of the RTU500 series is not necessary, but all users are logged out and a re-login
is required. After the reset all user accounts and passwords are reset to the default values. That
means the re-login must happen with a default user and password.
For the exchange of a password file the file must be downloaded from an RTU first. This is done
by selecting the button "Download" in the tab "Password File". When pressed an information status
bar appears like shown in the figure below. To save the downloaded password file on the host PC
select the button "Save".
To upload a before downloaded password file on another RTU the file can be dropped to the dotted
area shown in the figures above or the area can be clicked with the mouse. In the second case a
file select dialog appears to choose the password file to upload. In both cases a confirmation dialog
appears to confirm the upload. After confirmation with "Ok" the existing password file is replaced
by the uploaded file. If successful, the new password file is active directly. A reset of the RTU500
series is not necessary, but all users are logged out and a re-login is required.
In case of:
In case the password file is inconsistent between different CMU's the RTU500 series goes into a
restricted mode. In this mode a login is possible but the only function available is the harmonization
of the password file. The harmonization of the password file requires administrator permissions.
In restricted mode the Web server shows after login without administrator permissions the error
message displayed below.
ADVICE
Be sure to disable the advanced option "Show friendly HTTP error messages" if the Microsoft
Internet Explorer is used as Web client. Without this option the detailed error information of the
RTU500 series Web server are not shown. The option can be found in the "Advanced" tab of
the "Internet Options".
After login with administrator permission the RTU500 series Web Server shows the normal user
interface. But due to the restricted mode each function, besides the harmonization of the password
file, is locked. If a locked function is selected the Web server shows a corresponding error message,
like shown in the next figure.
To start the password file harmonization the link "User Management", found under the menu item
"Management", must be selected (see figure below). When selected the user interface for the ac-
count management appears. The last tab (called "Harmonization") in the user interface is used for
the password file harmonization by authenticate all available CMU's. Due to the sensible information
in the authentication the following notice has to be considered.
ADVICE
The web pages of this functionality require secure HTTPS access. It is not possible to open the
web pages with standard HTTP access.
Before a harmonization of the password file is possible, the authentication of the administration user
must be provided by the user for all detected CMU's. The provided authentications are compared
with authentications requested from the other CMU modules. Only if all authentications are correct
the password file can be harmonized and distributed to the other CMU modules.
The next figure shows an example for an RTU with 2 CMU's. For each detected CMU the rack and
slow address is shown. Furthermore there are input fields for user name, password and a button
to authenticate each CMU. A CMU is authenticated by typing a user account with administrator
permissions and selecting the button "Authenticate". A correct authenticated CMU is identified by
the check box on the right side.
When all CMU's are authenticated the distribution of the password file is started by selecting the
button "Harmonize" at the top of the page. The harmonization distributes the password file of the
connected CMU to all other CMU's. The distribution within the RTU can take a few seconds. If the
distribution was successful, the harmonized password file is active directly. A reset of the RTU500
series is not necessary, but all users are logged out and a re-login is required.
3 Diagnostics
3.1 System Log
The system log pages give information about the actual state of the RTU.
The logged information can be filtered in different areas (see "Fig. 30: System Log: General View"):
• All
• System
• Activies
• I/O boards
• Connected I/O devices
To view the status of the system events in the RTU500 series Web server the link "System Event
Status" must be selected. This item can be found under the navigation tile "Diagnostics" as shown
in the figure below.
The Hardware tree page gives information about the configuration of the RTU and about the actual
values of the process objects according the configuration in RTUtil500 (see "Fig. 34: Hardware tree
pages").
The channel number, process object ID and the current value of the data point is shown in the right
window. The value and the status information is updated cyclically.
The formerly functionality to perform any commands from this display directly to the connected pri-
mary process is obsolete and replaced by the TestMode functionality. Please see "Test & Simula-
tion" chapter.
Select a serial communication line, connected to a communication unit, to get static and dynamic
information about this line.
For support cases a system information file can be downloaded to a PC. This file is used by the
RTU support line to analyze the status of this RTU. The file includes all information visible in the Web
server in a condensed form and the generated PPP/VPN/E1/E2 debug output, so that the user can
investigate anomalous behavior during initialization and running of PPP/VPN connections between
RTU and remote peer.
– the Time administration test mode is temporary enabled (see Chapter 4.1)
– the user has the privileges to perform commands (see Chapter 2.5.3)
Following menu items refer to the different test mode views (see step 2 in figure below):
– Inputs and outputs (process data objects)
– System events and system commands
– Security Events
The first three columns give the user the possibility of filtering the signals to be displayed in the
grid. From left to right, these columns are the following:
– Signal type:
The first column includes the type of signal. The user can filter signals by selecting a signal type
from the drop list at the bottom of the column or by writing in the search box at the top of the
column. For example, if the user writes "i", all signals whose type contains an "i" (SPI, DPI, STI,
etc.) will be filtered. If the user writes now "pi", both SPI and DPI signals will be filtered.
– Signal identifier:
This column contains the full name of each signal, including the names of the different levels of
the signal tree to which the signal belongs. The user can filter signals by writing partial names of
the signals (e.g. the name of a group in the signal tree). It is also possible to write multiple parts
of the signal identifier in order to filter the signals which contain all these part in their names.
Fig. 42 is an example of this kind of filtering.
– Signal source:
The third column contains the name of the sub-device (or local IO) to which each signal be-
longs. Similar to the first column, the user can both select a name from the drop list at the bot-
tom of the column and write the name (or part of it) in the search box at the top to filter the sig-
nals to be showed in the grid.
At the top of the next to last column, there is a button called "Clear filter". By clicking on it, the user
clears all filters set in the three first columns of the grids.
The next three columns provide the dynamic information about the signal, i.e. its value and cause
of transmission. At the same time, they are also used by the user to specify the value (and cause
of transmission) with which the signals will be simulated. These columns are the following:
– Cause of transmission:
This column contains the cause of transmission with which the signal is sent. The possible val-
ues for each specific signal are listed in a drop list: SPONT (spontaneous), PERIOD (periodic),
BACKG (background), REQ (required), INTERROG (interrogated), RET_REM (returned by re-
mote command), RET_LOC (returned by local command), ACT (activation), ACT_CON (acti-
vation confirmation), DEACT (deactivation), DEACT_CON (deactivation confirmation) and AC-
T_TERM (activation termination).
The column includes a drop list with gray background at the bottom. If one of the options of
this gray drop list is selected, all drop lists in the column containing the same option will change
their selected option to the one specified at the bottom. (Fig. 43).
– Value:
This column displays the value with which the signal is transmitted. For signals whose values
are predefined (SPI, DPI, SCO, DCO and RCO), the value is represented as the selected option
of a drop list. In contrast, for signals whose values are integers (ITI and STI), natural numbers
(BSI and BSO), normalized percentages (AMI, DMI, ASO and DSO) or floating-point numbers
(MFI and FSO), the value is contained in an input box.
The qualifiers that accompany the value of a signal can be observed and/or set by right clicking
on the cell where the value is contained. After the right click, a dialog is prompted with the cur-
rent qualifiers, and the user has the possibility of changing them (Fig. 44).
The gray drop list at the bottom of the column is similar to the ones in the two previous columns. It
has no effect on the input boxes contained in the column; it only affects the drop lists.
The two final columns contain the elements that trigger the simulation of signals: the next to last
column includes buttons to force the simulation, while the last column contains a checkbox for each
row to enable multiple sequential forcing.
Note that the simulate button and checkbox for input signals (SPI, DPI, STI, AMI, DMI, MFI, BSI and
ITI) are not visible until these signals are disconnected from process (see Chapter , "Disconnecting
signals in monitoring direction").
On the other hand, the simulation buttons and checkbox for output commands (SCO, DCO, RCO,
ASO, DSO, FSO and BSO) are always visible. These output signals possess two simulation buttons:
"Se" (to perform a command selection) and "Ex" (to perform a command execution). The buttons
also signalize the status of the command (selection or execution) by means of bold letters. For
example, in Fig. 45, the first command is an execution, while the second is a selection.
To simulate an input signal or to send an output command, the user has just to click on the "Simulate"
or "Se"/"Ex" button in the row of the appropriated signal. A green flash in the row confirms that the
signal has been forced into the RTU and transmitted to the host systems (Fig. 46). In fact, each time
that a spontaneous change happens in a signal, the green flash appears in the row and the value
and cause of transmission fields are updated.
It is also possible to simulate a sequence of signals. The checkboxes in the last column are used
with this purpose. If the user selects multiple checkboxes in different rows (even in different pages
of the grid) and then clicks on any "Simulate", "Se" or "Ex" button, all the selected signals will be
simulated sequentially, from top to bottom (Fig. 47). The "All" button at the top of the column selects
(or deselects) all checkboxes in the current page of the grid.
A dialog will be prompted before starting a multiple forcing (Fig. 48). This may avoid undesired
sequence simulation.
The actions carried out in this control panel have only effect on the signals which are displayed at
that moment in the grid, and not on the rest of hidden signals.
In the control panel, the user can select to disconnect or reconnect signals, and in which direction
(monitoring, controlling or both). See figure Fig. 50 and figure Fig. 51 depict this:
When the appropriate direction and value are selected, the user must click on the "Proceed" button
to apply the changes.
When a signal is disconnected from process in monitoring direction, the RTU500 will block that
object's inputs, not sending them to the host system and not updating the RTU500 database with
the real value of the signal.
In the following example (Fig. 52), a SPI signal which belongs to a sub-device has been disconnected
from process in monitoring direction. Updates in the SPI's real value are blocked and not sent to the
host systems. Instead, the user can simulate the signal by means of the Test Mode user interface.
Regarding the user interface, process information inputs (SPI, DPI, STI, AMI, DMI, MFI, BSI and
ITI) are shown in the signals grid without checkbox and "Simulate" button. Only when they are
disconnected from process, the button and checkbox appear, and the text in the row (signal type,
identifier and source) turns bold green.
Therefore, process information inputs whose text is bold green are signals which are disconnected
from process in monitoring direction. That is, these are signals which are being simulated, since their
current values do not correspond with the real physical values of those inputs.
When a signal is disconnected from process in controlling direction, the RTU500 will block that
object's output commands, not sending them to the target local output board or sub-device. In
other words, the RTU500 blocks the physical execution of the output.
In the following example (Fig. 54), a SCO signal which belongs to a sub-device has been disconnect-
ed from process in controlling direction. Output commands sent by a host system to the SCO are
blocked by the RTU500 and not sent to the target-subdevice. Test Mode generates automatically a
response (positive or negative confirmation) to the command, and sends it to the host system. This
response is the same one that should be expected if the SCO would have not been disconnected
from process.
From the host system's point of view, there is no difference in the process, since the command
output workflow remains the same as usual (a command response is generated by the RTU500
and sent back to the host system). However, the physical output is not executed in the sub-device
(or local output board).
Regarding the user interface, process command outputs (SCO, DCO, RCO, ASO, DSO, FSO and
BSO) are always shown in the signals grid with checkbox and "Se"/"Ex" buttons, since it is always
possible to send output commands locally from the user interface. If the signals are not disconnected
from process in controlling direction, these outputs commands will be physically executed.
When the process command outputs are disconnected from process the text in the row (signal type,
identifier and source) turns bold. From this moment on, the outputs are blocked and the command
responses are simulated.
When at least one of the process command signals shown in the signals grid is disconnected from
process in controlling direction, an additional element appears in the control panel for process con-
nection (upper right corner of the user interface):
In this second row of the panel, it is possible to set the automatic simulation of command responses
and command reactions (drop list "Type"):
The "Command response" option gives the user the possibility to pre-define the command response
(positive or negative confirmation) that the RTU500 sends back to host systems when a command
output to a disconnected from process (in controlling direction) signal is received. The user shall
select an option from the "Value" drop list and click on the "Apply" button.
In the user interface, the text of the signals for which the automatic simulation of pre-defined com-
mand responses are set turns green. If the mouse pointer is placed over these rows, a tooltip shows
the value of the pre-defined command response (Fig. 59).
The second type of automatic simulation that the user can set in the control panel is "Command
reaction". This is the simulation of the process information signal defined by the user in RTUtil500 as
response indication for SCO and DCO objects (Process information parameter, SCO/DCO - General
parameters). That process information signal must have been disconnected from process as well
by the user.
The user shall select the value with which the command reaction is simulated (same or opposite value
to the output command's value) and, optionally, the delay in milliseconds between the command
response and the command reaction (Fig. 60). Finally, the button "Apply" must be clicked.
In the user interface, the text of the output command signals whose command reactions are being
automatically simulated becomes italic.
It is possible for the user to select the disconnection of the signals shown in the signal grid in "Both"
directions.
When this option is chosen (with value set to "Disconnect" and after clicking on "Proceed"), the
process information inputs shown in the signals grid are disconnected from process in monitoring
direction, while the process command outputs are disconnected in controlling direction. The behav-
ior is the same described in Chapter , "Disconnecting signals in monitoring direction" and Chapter ,
"Disconnecting signals in controlling direction".
Regarding the user interface, the visualization of the rows containing the disconnected signals
change in the same way described previously: the text corresponding to process information inputs
turns bold and green (and the "Simulate" buttons appear), while the one corresponding to process
command outputs becomes bold.
If at least one of the signals shown in the signals grid is a process command output, after discon-
necting signals in "Both" connections, the control panel will show the option to set automatic sim-
ulation, as explained in Chapter , "Disconnecting signals in controlling direction".
Reconnecting signals
To reconnect signals means to stop blocking inputs or outputs which had been previously discon-
nected from process.
Besides, when a process information input (SPI, DPI, STI, AMI, DMI, MFI, BSI and ITI) is reconnected
in monitoring direction, Test Mode updates the RTU500 database with the current real value of the
signal. The host systems receive this data update as well, and the Test Mode user interface displays
the signal's real value as well.
Regarding the visualization of the signals in the Test Mode user interface, the reconnected signals are
displayed with normal text again (no longer bold and/or green). The "Simulate" button and check-
boxes disappear for process information inputs, since it is not possible to simulate an input if the
signal is not disconnected from process.
If the number of simulated signals is zero, the indicator is black (Fig. 69).
If one or more signals are disconnected from process, the amount of them is displayed in the indi-
cator, whose color turns green (Fig. 70).
If the mouse pointer is placed over the indicator, a tooltip shows the number of signals that are
disconnected in monitoring and controlling direction (Fig. 71).
Each time the link is clicked a new text file will be generated, containing all logs since the beginning
of the session.
In this view's grid, there are two new columns: "ID" and "Description". They substitute the "Signal
Identifier" column from the Inputs and Outputs view. Their purpose is to help the user to filter the
signals properly. The rest of the columns and their functionality remains the same as explained in
Chapter 4.4.1
From the point of view of process disconnection, SEV are treated in the same way that process
information inputs (SPI, DPI, STI, AMI, DMI, MFI, BSI and ITI). That is, they are disconnected in
monitoring direction.
On the other hand, SSC are treated in the same manner as process command outputs (SCO, DCO,
RCO, ASO, DSO, FSO and BSO). They are disconnected in controlling direction. Note that automatic
simulation of pre-defined command responses and command reactions are not allowed here.
In this view's grid, the three first column help the user to filter the appropriate signals, while the two
last ones trigger the simulation. As the security events have no value or cause of transmission, this
grid has not such columns.
5 Operation
5.1 Starting the Integrated HMI
The Integrated HMI can be started directly from the navigation tile (see below) or from the 'Hardware
Tree'. This feature is only available, if an 'Integrated HMI' is configured.
Before an HMI application can be started, the following files must be uploaded to the RTU:
• HMILib.jar (using the Firmware File Manager (see chapter Chapter 2.2))
• HMILibInterface.jar (using the Firmware File Manager (see chapter Chapter 2.2))
• HMI Application (using the Configuration File Manager (see chapter Chapter 2.1))
One page of a list shows in maximum 50 events. To navigate inside the archive lists there are sev-
eral buttons above the list. The buttons have the following meanings (from left to right):
•
Go to end of the list to show the newest entries.
•
To scroll one page forward in the list (towards newer entries).
•
To scroll one page backward in the list (towards older entries).
•
Go to beginning of the list to show the oldest entries.
•
Download the complete list in predefined CSV format to the PC.
The RTU does no conversion of the format of the files in the archives. The file format depends on the
format provided by the IED. Different conversion routines are provided on request. For more details
see RTU500 series function description - part 7: archive functions (1KGT 150 946)
To view the security event archive in the RTU500 series Web server the link "Security Archive" must
be selected. This link can be found under the menu item "Operation" as shown in the figure below.
One page of the security event list shows in maximum 50 events. An example of the event archive
is shown in the next figure.
To navigate inside the list there are several buttons above the list. The buttons have the following
meanings (from left to right):
•
Go to end of the security event list to show the newest entries.
•
To scroll one page forward in the event list (towards newer entries).
•
To scroll one page backward in the event list (towards older entries).
•
Go to beginning of the security event list to show the oldest entries.
•
Download complete security event list in predefined CSV format.
For displaying and downloading of the security event list the following definitions apply:
• For each security event an event text is shown. The text depends on the specific event id and
is in the language selected for the whole RTU500 series Web server. To change the event text,
the text must be modified in the language file of the Web server (like the other texts in the Web
server as well).
• All time stamps of the security events are shown in local time (local time zone) as defined for
the whole RTU.
• When downloading the security event list the resulting CSV file contains the events in the same
format and language as shown in the Web server display. This applies as well for the time
stamps that are in local time.
• The size of the security event archive is configurable in RTUtil500. If the configured limit is
reached the oldest security events in the archive are overwritten, when new events occur.
For more information about the localization support see chapter "Language Management". For de-
tailed information about the available security event archive limits please refer to the RTU500 series
Security Deployment Guideline [1].
6 Engineering
6.1 Use case 1: Pre-configured RTU520
RTUl500
RTU520 storage
With this engineering use case the RTU520 is preconfigured with RTUtil500. Within the RTUtil500
configuration several parameters can be defined as online engineering parameters. These parame-
ters must then be configured via the Web server. For more details please referr to the demonstration
video: Web server engineering: Pre-configured RTU520.
Web Applicaon
With this use case the complete RTU520 configuration will be done via the Web server, without
using RTUtil560. For more details please referr to the demonstration video: Web server engineering:
RTU520 easy engineering.
For the identification the RTU500 series Web server uses as default self-signed public key certificates
not issued by a certification authority (CA). The default self-signed certificates are created at startup
depending on the configuration. In addition the RTU500 series Web server supports the upload of
external generated HTTPs certficates. This allows to use trusted certificates issued by a certification
authority (CA).
Client authentication with user certificates is not supported by the RTU500 series. The authentication
of the user is ensured by a user name and a password.
ADVICE
For security reasons, the web client has to be closed after each working session. This prevents
the usage of supplied user names and passwords by unauthorized persons.
The following chapters describe configuration, access and certificate handling for the secured
RTU500 series Web server.
• Option to disable the Web server on selected Ethernet interfaces. This is possible in single and
multiple CMU systems. The Web server must be enabled on at least one Ethernet interface to
be able to access the RTU at all. The Web server is enabled on all Ethernet interfaces by de-
fault.
• Option to secure the Web server access with HTTPS. This option can be selected on each
CMU. The HTTPS option is enabled by default
• Define the authentication type for the secure Web server. Possible are the default self-signed
certificate or an uploaded external certificate stored in the certificate store of the CMU.
• Set an entry in the certificate store of the CMU to upload external HTTPS certificates for the
Web server authentication.
In RTUtil500 the option to disable the Web server is placed at the CMU in the configuration tab of the
Ethernet interface, e.g." E1" (Hardware tree only). The figure below shows the option in the RTUtil500
user interface. The Web server is disabled by deselecting the checkbox "Enable Web server".
As shown in the next figure, the configuration parameters related to the secure Web server are
located in the "General" tap at a CMU module (Hardware tree only). To secure the RTU500 series
Web server with a self-signed certificate follows these steps:
For the usage of an external HTTPS certificate, the certificate store has to be configured at first.
That means an entry has to be added to the certificate store representing the certificate used for
the Web server authentication. The certificate store configuration opens by pressing the button
"Configuration" shown in the figure above (near the text "Certificate Storage"). When selected a
dialog appears with several entries for certificates. Each entry represents a certificate that shall be
transferred to the CMU. To add a certificate, select the check box at the entry number and give the
entry a descriptive name. An example of the certificate store configuration is shown in the figure
below.
Together with the certificate store the steps to secure the RTU500 series Web server with an external
certificate are:
1 Configure an entry in the certificate store representing the external certificate to upload. Give
the entry a descriptive name like "Web server certificate".
2 Select the checkbox "Secure HTTPS Web server".
3 Select in the drop-down menu "Web-server authentication" the certificate from the store. Here
the name given in the first step is selected.
4 Upload the external HTTPS certificate via the RTU500 series Web server.
Further information about the upload of external HTTPS certificates can be found in chapter "External
certificate".
The default Web server certificates used by the RTU500 series are self-signed and not issued by
a certification authority (CA). As result an actual web client shows a warning messages concerning
the missing CA, if the Web server is accessed with HTTPS. To avoid this warning message a trusted
external certificate must be configured and uploaded to the RTU500 series.
If the Web server is configured for HTTPS a standard access is not possible anymore. In case of
a standard access the Web server redirects the access to the secure pages of the RTU500 series
Web server.
If the Web server is not configured for HTTPS, a secure access is possible as well. There are no
restrictions in this case besides the possible warning message from the self-signed certificate.
See chapter "RTUtil500 configuration" for configuration and chapter "External certificate" for upload
of external certificates.
This requires for the RTU a public/private key pair and a corresponding public key certificate. There
are two possibilities for this purpose. First the self-signed certificates generated by the RTU500
series firmware can be used or a trusted, extern generated certificate can be uploaded to the RTU.
When uploading, a certificate must be available for each CMU because the Web server can be
accessed on any CMU. Further information about the self-signed and extern generated certificates
can be found in the following two chapters.
The certificate contains HTTPS protocol specific information like the public key and identity informa-
tion. The identity information are set as follows.
• The identity information like country, locality and organization name are predefined to the ABB
AG, Mannheim, Germany. These cannot be changed.
• The common name of the identity is set to the configured IP address of the CMU Ethernet in-
terface E1. The common name represents the host name (server name) the web client uses to
access the Web server. In case the configuration of the IP address changes a new certificate is
generated and stored in the internal flash (overwrites the existing one).
• In subject alternative name the IP address of the Ethernet interface E1 and the USB interface
are defined. This allows the secure HTTPS access via USB as well.
• The serial number of the certificate is set to 1 for the first created certificate and increased
every time a new certificate is generated due to a configuration change.
• The expiration date of the certificate is set the 1. January 2070.
• The generated end-entity server certificate shall be signed and issued by a trusted root or inter-
mediate certificate. This avoids any warning messages in the Web client when accessing the
RTU500 series Web server via HTTPS.
• For a correct end-entity Web server certificate the attribute "keyUsage" must contain the en-
cryption values "keyEncipherment" and "dataEncipherment", at least. And the attribute "ex-
tendedKeyUsage" must contain the server authentication value "serverAuth".
• The common name of the certificate identity must not be set to an IP address used in the RTU.
It is sufficient to set the attribute "IP Address" in the subject alternative name to an used IP ad-
dress. Depending on the policies in your organization setting the attribute "DNS Name" might
be necessary as well..
• To use the same certificate for several CMU's or RTU's a list of IP addresses and DNS names
can be defined in the subject alternative name.
• The generated certificate must contain the public/private key pair of the end-entity certificate
and the whole certificate chain, including root and intermediate certificates.
• For uploading the generated certificate must be stored in PKCS#12 format with the file ending
".p12".
The upload of an external generated certificate is done via the RTU500 series Web server. In the
Web server menu the link "Certificate Management" is the entry point for the certificate upload. This
link can be found under the menu item "Management" as shown in the figure below. Due to the
sensible information in the certificate upload the following notice has to be considered.
ADVICE
The web pages of this functionality require secure HTTPS access. It is not possible to open the
web pages with standard HTTP access.
The shown link starts the user interface for the certificate upload. In the user interface are two areas.
The upper area contains the certificates actually uploaded to the RTU500 series and the lower area
controls the upload. The following figure shows this user interface. As there is no trusted, external
certificate is uploaded in the example figure, a certificate error is shown as explained in chapter
above.
To upload a certificate the following steps has to be executed in the lower area of the user interface:
1 Select the description of the certificate to upload in the column "Certificate description". In the
selection all in RTUtil500 configured entries of the certificate store appear. The selection text is
the descriptive name set in RTUtil500 as explained in chapter about the RTUtil500 configura-
tion.
2 Select a certificate file by dropping the file on the lower area or by using the file open dialog that
appears when clicked with the mouse. The certificate file must be in PKCS#12 format with the
file ending ".p12".
3 Enter the private key passphrase by pressing the lock symbol on the left side. When pressed a
dialog appears to enter the passphrase. The passphrase is used to decrypt the private key of
the certificate after the upload. For storing on the memory card the private key is re-encrypted
with a memory card specific key. The enter passphrase is not stored on the RTU500 series.
When all steps are finished the certificate can be uploaded by pressing the upload button (see figure
below). The upload button appears not before all required information are set.
When the upload is finished the RTU500 series has to be restarted to activate the certificate. It may
be necessary to restart the Web client as well, to recognize the new certificate in the client. After a
successful upload and restart the certificate management looks like shown in the next figure. The
upper area contains now the information about the uploaded certificate and the certificate error due
to the missing CA is not shown anymore.
For certificate generation SDM600 is recommended (System Data Manager SDM600 - User Manual).
8 PPP Installation
8.1 Windows 7
Before starting the installation, be sure that the current user has administrator rights in the Windows
7 operating system. These rights are needed to install new software on the computer.
To create and establish a PPP connection to an RTU, select Start > Control Panel > Network and
Sharing Center.
Select the device e.g. Communications cable between two computers #2.
Fill in an arbitrary Dial-up phone number to enable Connect. However, there is no option for Direct
Serial Cable Connection on this dialog. Enter a suitable Connection name.
To configure the PPP connection, select Start > Control Panel > Network and Sharing Center
> Change adapter settings.
Right-click on the connection created from the previous steps and click Properties.
Remove the Phone number and verify below Connect using Communication cable between two
computers with correct COM port is activated. Click Configure….
For the Maximum speed (bps), select 38400 from the drop-down list.
Enable the settings from the figure above and click Advanced….
From Start > Control Panel > Network and Sharing Center > Change adapter settings select
Connect from context menu for the new connection.
If authentication is configured in the RTU enter User name and Password and click Dial.
If the connection to the RTU is established, start the Internet Explorer without using a proxy server
or bypass the proxy server for configured RTU IP address from Tools > Internet Options > Con-
nections > LAN settings.
The USB interface on the CMU modules works as USB RNDIS target device. RNDIS host is a
Windows 7 computer. RNDIS interface’s IP address on the RTU is 169.254.0.10. The USB RNDIS
Device running on Windows host can get IP settings assigned automatically from the "link local"
block 169.254.0.0/16 (APIPA - Automatic Private IP Addressing). As described in RFC3927, it is
allocated for communication between hosts on a single link. The Windows host can obtain this
address by auto-configuration. The alternative to assign manually the IP address 169.254.0.1 on
Windows 7 host is described below.
If firewall is used on Windows 7 computer, please adjust firewall settings to allow communications
via the RNDIS interface. Subnet mask is 255.255.0.0.
The RNDIS driver is part of the Windows 7 installation, but you need to tell to the system where
it can find it. Before starting the driver installation, be sure that the current user has administrator
rights in the Windows 7 operating system. These rights are needed to install new driver software
on the computer.
This chapter describes how to install software for USB RNDIS device and setup the network interface
on Windows 7.
9.1 Windows 7
Install RTUtil500 Version 11.0.1.0 or higher.
Connect the running RTU and the Windows 7 machine via USB cable. As soon as the RTU is
detected the Windows 7 operating system will try to automatically find a driver for it, but fails.
The Windows 7 machine detects the new USB RNDIS Target Device and prompts you to install it.
The following dialog box "Driver Software Installation" appears. Select the “Close” button.
Launch the "Device Manager" management console (Start / Run / devmgmt.msc) or go to the
computer management console (right click on “My Computer” and choose “Manage” and open
device manager.
The USB RNDIS Target Device is marked with an exclamation mark to point out that its driver is
not running.
Right click on USB RNDIS Target Device and choose “Update Driver” from context menu. You
will be prompted with the driver selection wizard.
Answer the question "How do you want to search for driver software?". Select the option "Browse
my computer for driver software".
You will be prompted with the driver selection dialog. In this dialog click the ”Browse…” button
and select the folder that contains the USB RNDIS driver information file for RTU hardware (wrs_us-
b_rndis.inf):
Answer the security warning "Windows can’t verify the publisher of this driver software". Select the
option "Install this driver software anyway".
The installation wizard will finish the installation and notify you upon complete. Click the “Close”
button to exit the installation wizard.
The USB RNDIS device is now installed on the Windows 7 machine. RNDIS emulates a network
connection. A new network adapter is displayed in the Device Manager management console.
Per default a local IP address is obtained automatically for the USB RNDIS device.
Alternatively it’s possible to assign manually the IP address 169.254.0.1 on Windows 7 host. The
Internet Protocol (TCP/IP) Properties dialog is used to set a static IP address for the new con-
nection. Select context menu for the new Local Area Connection / Properties / Internet Protocol
Version 4 (TCP/IPv4) / Properties
IP address: 169.254.0.1
Select “OK” and “Close” buttons. The USB RNDIS device is now configured on the Windows 7
machine and is available for use.
The new network interface on the RTU is configured automatically with the IP address 169.254.0.10.
That means different IP addresses in the same subnet are configured on each side and communi-
cation can be started. The result is the same as creating two network devices and giving one to the
RTU and one to the Windows 7 machine.
ping 169.254.0.10
Launch web browser with URL (If necessary bypass proxy server.):
http://169.254.0.10
When the USB RNDIS device is up and running you will be able to use it as you do with devices
with a “regular” Ethernet connection to the RTU.
10 Glossary
AMI Analog Measured value Input
Note:
The specifications, data, design or other information contained in this document (the “Brochure”)
- together: the “Information” - shall only be for information purposes and shall in no respect be
binding. The Brochure does not claim to be exhaustive. Technical data in the Information are only
approximate figures. We reserve the right at any time to make technical changes or modify the
contents of this document without prior notice. The user shall be solely responsible for the use of
any application example or information described within this document. The described examples
and solutions are examples only and do not represent any comprehensive or complete solution. The
user shall determine at its sole discretion, or as the case may be, customize, program or add value
to the ABB products including software by creating solutions for the end customer and to assess
whether and to what extent the products are suitable and need to be adjusted or customized.
This product is designed to be connected to and to communicate information and data via a network
interface. It is the users sole responsibility to provide and continuously ensure a secure connection
between the product and users or end customers network or any other network (as the case may
be). The user shall establish and maintain any appropriate measures (such as but not limited to
the installation of firewalls, application of authentication measures, encryption of data, installation of
anti-virus programs, etc) to protect the product, the network, its system and the interface against any
kind of security breaches, unauthorized access, interference, intrusion, leakage and/or theft of data
or information. ABB AG is not liable for any damages and/or losses related to such security breaches,
any unauthorized access, interference, intrusion, leakage and/or theft of data or information.
ABB AG shall be under no warranty whatsoever whether express or implied and assumes no re-
sponsibility for the information contained in this document or for any errors that may appear in this
document. ABB AG's liability under or in connection with this Brochure or the files included within
the Brochure, irrespective of the legal ground towards any person or entity, to which the Brochure
has been made available, in view of any damages including costs or losses shall be excluded. In
particular ABB AG shall in no event be liable for any indirect, consequential or special damages,
such as – but not limited to – loss of profit, loss of production, loss of revenue, loss of data, loss
of use, loss of earnings, cost of capital or cost connected with an interruption of business or oper-
ation, third party claims. The exclusion of liability shall not apply in the case of intention or gross
negligence. The present declaration shall be governed by and construed in accordance with the
laws of Switzerland under exclusion of its conflict of laws rules and of the Vienna Convention on the
International Sale of Goods (CISG).
ABB AG reserves all rights in particular copyrights and other intellectual property rights. Any repro-
duction, disclosure to third parties or utilization of its contents - in whole or in part - is not permitted
without the prior written consent of ABB AG.