Dial-up modems can be connected to the serial, or Ethernet, communication interface of a CMU.
Multiple devices can be connected to one or several modems. Redundant communication lines to subordinate devices can also be configured. The pool of modems connected to the system is managed by RTU560.
The Modem Pool function is controlled by means of SSCs. Generation of the SSCs is based on commands from the NCCs. For more information, refer to the relevant sections in this document.
SSC ( #3 … #11 ): System Single Commands
Function Description Release 11
7 Start-up, Configuration and Time Management
7.1 Start-up procedures
The RTU500 series supports two start-up types:
Single CMU start-up
Multiple CMU start-up
Only the RTU560 supports multiple CMU start-ups. The single CMU start-up is a special case of the multiple CMU start-up.
An RTU560 series system may contain several CMUs, e.g., 560CMU02 R0002, 560CMU05. Activities, such as communication protocols, I/O bus interfaces or PLC functions, may be configured as required to be running on different CMUs.
RTU500 series supports the following start-up procedures:
RTU System Start
Power ON or reset of the RTU system is common to all RTUs of the RTU500 series
RTU560 CMU Start
Power ON or reset of a CMU of an RTU560 system
RTU560 CMU Integration
Hot-plugging of a CMU into a running RTU560 (only in RTU560 systems with multiple CMUs)
RTU Protocol Restart
Communication protocols often provide specific methods to restart the RTU.
The RTU may support various protocols. For information on the available restart methods, refer to the relevant protocol description.
7.1.1 RTU System Start
System start of a RTU500 series (Power ON or reset of the RTU) is managed by System Control, which is running on the master CMU. The system start sequence is as follows:
After CMU start (see chapter RTU560 CMU start (page Fehler!
Verweisquelle konnte nicht gefunden werden.)), System Control requests the configured boards and waits 5 s for their registration (only for RTU560).
RTU System Control starts the configured activities on the registered CMUs in the following order:
Archive and Print functions
Host Communication Interfaces (slave protocols, no communication)
Subdevice Communication Interfaces (master protocols)
I/O bus interfaces (PDP)
PLC and local function tasks
Subdevice interfaces and I/O bus request data from subdevices and I/O boards. System Control waits until they report their databases to be up to date.
The configured host interface(s) start(s) communication with the NCC.
System monitoring is started to enable removal and insertion of CMUs (only for RTU560).
7.1.2 RTU560 CMU start
When a CMU is started after Power ON or a reset command by an NCC or web server of an RTU560, the CMU performs the following start-up sequence:
Initialize and test hardware (RAM, FLASH, watchdog, etc.), load firmware from flash memory
Send the following system message: “CMU x: Starting up …”
If a CMU starting to participate at the system bus, the SEV “CMU x:
operable” is send.
Check if other CMUs are present in the RTU for 5 s. If other CMUs are present in the RTU for 5 s, the CMU compares its own firmware and configuration to that of all CMUs present in RTU in the following manner:
The major release version number of the firmware (e.g.: 11 for a Version 11.1.1.0) must be the same on every CMU. If the version number of the firmware release is not the same on every CMU, the CMU stops further initialization and sends the following system message: “CMU x:
(Firmware x.x.x.x) Firmware version incompatibility in system”. It then waits for a new firmware to be loaded, and a reset to be performed.
The .rcd configuration (RTU Configuration Data) must be present and identical on every CMU. If the .rcd configuration is not present and identical on every CMU, the CMU stops further initialization, sends the following system message: “CMU x: Configuration file not consistent in starting system. Local file created at yyyy-mm-dd hh:mm.ss". It then waits for a new .rcd configuration to be loaded, and a reset to be performed.
Check if the configuration is formally valid (correct CMU type, correct rack and slot address). If the configuration is not formally valid, the CMU stops further initialization, sends the following system message: CONFIG-ERROR ON CMU #X: WRONG RACK OR SLOT ADDRESS.It then waits for a new .rcd configuration to be loaded and/or replacement to be performed.
Start activities as called by System Control. If the start of an activity fails, the CMU sends the following system message: <ACTIVITY TYPE> CMU x:
<ACTIVITY STATE><ACTIVITY-ERROR TYPE>. For more information, refer to the table System message text.
If all activities have been started successfully and the CMU is in system administration mode active or non-redundant, the SEV “CMU x: active” is send by the CMU.
7.1.3 RTU560 CMU integration
In a system with multiple CMUs, a single CMU may be integrated into a running RTU560. During the integration process, any activities currently running on the RTU continue their operation.
To be able to integrate a CMU into a running RTU560, the following condition must be fulfilled:
The CMU must be configured in the RTU560.
During integration, a CMU runs a similar start-up sequence to the one described in the section RTU560 CMU start (page Fehler! Verweisquelle konnte nicht gefunden werden.), with the following exceptions:
Function Description Release 11 Start-up, Configuration and Time Management Start-up procedures
If any of the configuration elements (.rcd or password) is missing or differs from the files on the other CMUs, the integrating CMU tries to load the missing configuration from a running CMU. The integrating CMU then automatically resets in order to perform a CMU start with the new configuration.
During integration of a CMU into a running system, the board databases are synchronized to ensure, that the integrated CMU has the same information as the already running CMUs.
Upon completion of the integration process, the host interfaces on the integrating board (if present) start communication with the NCC.
If a formerly active CMU of a redundant pair is reintegrated into the system (e.g., after maintenance or repair), it becomes the stand-by CMU of the redundant pair.
The integration of a CMU is signaled by SEVs in the following way:
Non-redundant CMU:
SEV “CMU x Inoperable” = 'FALSE', SEV “CMU x active” = 'TRUE'
Redundant CMU:
SEV “CMU x Inoperable” = 'FALSE', SEV “CMU x active” = 'TRUE'
7.1.4 RTU560 CMU removal
A CMU may be removed from a running RTU560. Any activities running on other CMUs continue their operation.
CAUTION
If a CMU running I/O buses or subdevice communication interfaces is removed, a trigger is sent to the remaining boards in the RTU560 to flag the related process data in their respective databases as being invalid.
The removal of a CMU is signaled by SEVs in the following way:
SEV 'CMU x Inoperable' = 'TRUE'
SEV 'CMU x Active' = 'FALSE'
If the active CMU of a redundant pair is removed, the system performs a restart of the standby CMU. After a successful restart, the standby CMU becomes the active CMU. The state of the new active CMU is signaled by SEVs in the following way:
SEV 'CMU x Inoperable' = 'FALSE'
SEV 'CMU x Active' = 'TRUE'
7.2 RTU500 series configuration
7.2.1 General requirements
The RTU needs valid configuration for operation. An RTU with multiple CMUs must keep equal configurations in each CMU.
The RTU configuration data (RCD) file contains hardware, protocol and process data point information.
The password configuration has a default setting in a new RTU and may be changed via the web server.
The RCD configuration is provided by means of a binary files with .rcd suffix. The files are stored non-volatile in FLASH memory and are copied into RAM at CMU boot for read-only access.
The files are generated with the configuration tool RTUtil500 by command (See RTUtil500 User's Guide, chapter Generate RTU-Files). The configuration files may be loaded to the RTU via the web server of the RTU500 series or via NCC using a file transfer service of the communication protocol.