Professional Documents
Culture Documents
6802979C15-J
AB
Info-ZIP
Version:
Description:
Software Site:
http://www.info-zip.org/
Source Code:
The Source Packages for this software are available from the original Software Site, or may be acquired
from Motorola. To obtain the Software from Motorola, please contact Motorola using the methods
described in the preamble of this Legal Notices and End User License Agreement Document.
License:
This is version 2005-Feb-10 of the Info-ZIP copyright and license. The definitive version of this
document should be available at ftp://ftp.info-zip.org/pub/infozip/license.html indefinitely.
This software is provided "as is," without warranty of any kind, express or implied. In no event shall Info-ZIP or its
contributors be held liable for any direct, indirect, incidental, special or consequential damages arising out of the use of or
inability to use this software.
Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and
redistribute it freely, subject to the following restrictions:
1. Redistributions of source code must retain the above copyright notice, definition, disclaimer, and this list of conditions.
2. Redistributions in binary form (compiled executables) must reproduce the above copyright notice, definition, disclaimer,
and this list of conditions in documentation and/or other materials provided with the distribution. The sole exception to this
condition is redistribution of a standard UnZipSFX binary (including SFXWiz) as part of a self-extracting archive; that is
permitted without inclusion of this license, as long as the normal SFX banner has not been removed from the binary or
disabled.
3. Altered versions--including, but not limited to, ports to new operating systems, existing ports with new graphical interfaces,
and dynamic, shared, or static library versions--must be plainly marked as such and must not be misrepresented as being
the original source. Such altered versions also must not be misrepresented as being Info-ZIP releases--including, but not
limited to, labeling of the altered versions with the names "Info-ZIP" (or any variation thereof, including, but not limited to,
different capitalizations), "Pocket UnZip," "WiZ" or "MacZip" without the explicit permission of Info-ZIP. Such altered versions
are further prohibited from misrepresentative use of the Zip-Bugs or Info-ZIP e-mail addresses or of the Info-ZIP URL(s).
4. Info-ZIP retains the right to use the names "Info-ZIP," "Zip," "UnZip," "UnZipSFX," "WiZ," "Pocket UnZip," "Pocket Zip," and
"MacZip" for its own source and binary releases.
Credits:
N/A
Table of Contents
SCOPE ................................................................................................................................................................. 1
ACE3600 I/OS .................................................................................................................................................... 2
I/O Configuration .......................................................................................................................................... 2
I/Os and the Application ................................................................................................................................ 3
I/Os Hot Swap................................................................................................................................................ 3
I/O Module States .......................................................................................................................................... 3
Sleep Mode..................................................................................................................................................... 4
Hardware Tests.............................................................................................................................................. 4
Freeze Mode .................................................................................................................................................. 4
Select Before Operate DOs............................................................................................................................ 5
I/O Expansion ................................................................................................................................................ 7
I/O Expansion Frames in the ACE3600 Database ........................................................................................ 8
I/O Expansion Configuration ........................................................................................................................ 8
Time & Sequencing Synchronization of I/O Expansion................................................................................. 9
AUTOMATIC I/O RECOGNITION ......................................................................................................................... 10
POWER MANAGEMENT ...................................................................................................................................... 12
Configuration............................................................................................................................................... 12
Constraints................................................................................................................................................... 13
SAFE FIRMWARE DOWNLOAD ........................................................................................................................... 14
FLASH FILE SYSTEM ......................................................................................................................................... 15
General ........................................................................................................................................................ 15
User Generated Flash Files......................................................................................................................... 16
Accessing Flash Files .................................................................................................................................. 16
Writing Flash Files ...................................................................................................................................... 17
Logging Flash Files..................................................................................................................................... 17
Flash File Headers ...................................................................................................................................... 17
Flash Files Diagnostics ............................................................................................................................... 18
ACCESSING DATABASE VARIABLES VIA COORDINATES .................................................................................... 19
Definitions.................................................................................................................................................... 20
EVENT DRIVEN SOFTWARE ............................................................................................................................... 22
Definitions.................................................................................................................................................... 22
Event Driven Mechanism............................................................................................................................. 23
Event Driven Tables .................................................................................................................................... 24
How to Use the Event Driven Software ....................................................................................................... 25
FAST EVENTS .................................................................................................................................................... 31
Events Triggers............................................................................................................................................ 31
Fast Event Definition and Configuration .................................................................................................... 31
Fast Event Scheduling ................................................................................................................................. 32
Enabling/Disabling Fast Events .................................................................................................................. 32
Monitoring of Fast Events ........................................................................................................................... 33
Fast Events Diagnostics............................................................................................................................... 33
Testing Fast Events...................................................................................................................................... 33
Fast Events and Automatic Recognition ...................................................................................................... 34
RTU AND POWER SUPPLY REDUNDANCY ......................................................................................................... 36
Redundant RTU Site Configuration............................................................................................................. 37
3-i
Table of Contents
Table of Contents
iii
Scope
This reference manual provides useful background information on ACE3600 advanced system
features, communication features, and specialized utilities and features.
The system features include:
I/Os
Power Management
Fast Events
Network Configuration
Firewall
ACE IP Gateway
MDLC Encryption
Protocol Analyzer
PID Loop
Enhanced PID
Irrigation
ACE3600 I/Os
I/O Configuration
The basic ACE3600 RTU can include up to eight I/O modules in any combination, arranged in
a single frame and numbered 1-8. Optionally, I/O expansion frames can be added to the
ACE3600 RTU, increasing the number of I/O modules controlled by the CPU module on the
main frame. I/O expansion is based an expansion LAN switch installed on the main frame, and
an expansion module plus a power supply installed on the I/O expansion frame. Up to 110
I/Os can be connected to the ACE3600, by using two expansion LAN switches on the main
frame and thirteen I/O expansion frames. For details on setting up a system with I/O
expansion, see the ACE3600 RTU Owners Manual.
The RTUs I/O modules are configured in the ACE3600 STS I/O tab during site configuration
(see figure below.) The module types are selected from a drop-down list and include an FLN
number which is also printed on a label on the left side of the physical module. Two different
DI/DO FET modules (FLN3553, FLN3554) are available, with up to 16/32 user connections
which can be configured as either DI or DO, in groups of eight. For a list of the available I/O
modules, see the ACE3600 STS User Guide or the ACE3600 RTU Owners manual.
The I/O tab includes a field, Enable auto I/O modules recognition at startup, which instructs
the unit to automatically recognize I/O modules when it is started up. This saves the user time
when configuring the site in the STS. If automatic recognition is enabled, no I/O modules can
be defined for the site and the I/O configuration must be uploaded from a unit. For more
information, see Automatic I/O Recognition below.
Settings for I/O modules and individual I/Os can be set using the Advanced Configuration of
the specific I/O module. This includes defining values such as DO power source, AI/DI filters,
and AI differential. For details, see the Customizing the Configuration of a Site section of the
ACE3600 STS User Guide.
2
ACE3600 I/Os
Running: The I/O module in the slot matches the one in units site configuration. (In this
case the application can run.)
Failed: The I/O module is missing or the module in the slot does not match the one in
units site configuration. (In this case the application cannot run.)
Mode Selected: e.g. Freeze mode or Sleep mode. (Determined by user or application.)
ACE3600 I/Os
Sleep Mode
Each I/O module can be switched by the user application program to Sleep Mode. In Sleep
Mode, the module does not function and the power consumption is minimized. During Sleep
mode, the user application program will get the predefined values (PDV) or keep the last value
(KLV) for each I/O. The PDV/KLV values are set in the I/O link table of the application
program. For more information, see the Application Programmer chapter of the ACE3600 STS
User Guide.
Hardware Tests
The RTUs I/O modules can be tested using the STS Hardware Test utility. I/O module
parameters can be retrieved, the state of the I/Os can be scanned, and the application started
and stopped. The I/O module LEDs can be turned on and off. Information on the I/O module
power supply (DI/AI modules only) can also be retrieved. Individual I/Os can be tested.
During hardware tests, various values and settings can be changed by the user. These changes
will revert to their previous values/settings (saved by the system) under the following
circumstances:
Freeze Mode
The STS Hardware Test utility enables the user to test inputs and outputs while the user
program is running. The I/O module can be set to Freeze mode. No actual values will be
read/written to the application until the module is unfrozen. The application will continue to
run; all unfrozen I/O modules will continue to interact normally with the application while the
frozen module will not be impacted by the application at all.
The user program will get the predefined value (PDV) or keep the last value (KLV) of each
input in the module instead of the actual inputs value. The DO values will keep the last value
they had at the time the module was frozen.
If the hardware test involves reading inputs only, the I/O module generally need not be frozen.
When testing outputs, the I/O module should be frozen to ensure proper execution of the
application.
If the user does not unfreeze the module, the STS will prompt to unfreeze it when closing the
Hardware Test utility or after ten minutes have elapsed.
For more information, see the Performing Hardware Tests section of the ACE3600 STS User
Guide.
ACE3600 I/Os
Relay is selected.
The SBO feature can be implemented in the user C or ladder application. The application can
perform each SBO operation separately (select, check, operate) or have the system perform the
select, check and operate automatically. The user specifies the duration of the relay operation
(or forever) as a parameter.
IMPORTANT: Unlike standard DOs (where several DOs can be activated at once), only one
SBO DO per RTU can be activated at a time. However, a single Scan In of the Select Back
Indication and Activate Back Indication can be done at once for all DOs in a specified
module.
[50]:
Time to wait for the hardware Check. After this timeout, a hardware failure message is sent.
(Internal use only).
SBO relay select timeout
[5000]:
This parameter determines how much time may elapse between the Select and the Operate.
After this timeout, the SBO DO will be reset (the Select is aborted.) This parameter is only
relevant when the user calls Select, Check, and Operate separately. When the system performs
the SBO automatically, this parameter is not checked.
ACE3600 I/Os
Description
SBO
SBO_select
Performs Select of the specified SBO. After calling this function, the
user program should check the SBI back indication.
SBO_operate
Performs Operate of the specified SBO. This function is called after the
check indicates that the desired SBO DO relay was selected. The
duration of the operation is determined in the SBOduration Reserved
Value.
SBO_reset
Resets the current operation and selection. All SBO DOs are unselected.
The specified SBO is a discrete output (d-o) type which is I/O linked to SBO_1 SBO_X in a
specific module. To link the output:
1. In the ladder database, generate a (d-o) column in a single or multi column table.
2. Link the specified I/O (rack and module) to SBO_X using the drop-down list.
3. Pass the linked cell to the CAL operator as the second parameter. (You can use a
dynamic index.)
In order to check the select back indication(s) SBI after selecting a DO, you must do as
follows:
1.
In the ladder database, generate a (d-i) column in a single or multi column table.
2.
Link the I/Os (rack and module) to SBI_1 SBI_X using the drop-down list.
3.
In order to check the back indication(s) BI after operating a DO, you must do as follows:
1.
In the ladder database, generate a (d-i) column in a single or multi column table.
2.
Link the I/Os (rack and module) to BI_1 BI_X using the drop-down list.
3.
For details on the CAL operator, see Appendix B: Ladder Diagram Language of the ACE3600
STS User Guide. For details on programming ladder applications, see the Application
Programmer section of the ACE3600 STS User Guide.
ACE3600 I/Os
SBOstatus - This value indicates the status of the SBO process (i.e. if the SBO was selected or
operated already). In this way, the application can know whether to check back indications or
whether another SBO operation can be generated.
SBOerror - This value is indicates the type of error from the last SBO step.
For details on these three values, see Appendix C: Database Tables and Data Types of the
ACE3600 STS User Guide.
I/O Expansion
Before reading this section and implementing the I/O expansion feature, please consult the
detailed description in the ACE3600 RTU Owners Manual.
7
ACE3600 I/Os
I/O expansion is not available for ACE IP Gateway units or IRRInet-ACE RTUs. I/O
expansion is available for ACE3600 RTUs from firmware version 13.00.
ACE3600 I/Os
For example, in a system with thirteen frames, the IP address range might be 10.100.100.100
(main CPU) to 10.100.100.113, or 0.0.0.0 to 0.0.0.13.
The Expansion module sets main frame CPU as NTP server parameter (Advanced ->
I/O Expansion Manager) should be set to Enable.
If the user uses the main CPU as an NTP server for time synchronization, the sequencing
mechanism is still performed by the main CPU and the time is synchronized via NTP.
ACE3600 I/Os
11
Power Management
The ACE Power Management feature enables ACE3600 RTUs which run on batteries to
reduce the power consumption, and thus reduce the frequency of the RTUs battery
maintenance. Power management is especially important for RTUs located in the field with
limited access, or RTUs integrated in systems with low levels of activities (i.e. RTUs are
frequently idle.)
Power management for an RTU is defined and implemented by the user using a ladder/C
application program to control the power supplies in the system.
I/O modules and their power supplies are defined as new element types in the user tables. The
current state of the I/O module or power supply can be retrieved using a Scan(). A power
consuming element can be turned on/off as a result of an explicit user control.
IMPORTANT: It is the responsibility of the user when defining the application to
operate the RTU in accordance with its power management requirements. For
example, if the user tries to transmit data over a communication interface which has
been powered off, the transmit will fail (as it would in the case of a disconnected
cable.)
The following RTU components can be controlled using power management:
I/O modules - Put an I/O module to sleep or wake up an I/O module according to the user
application request; retrieve an I/O modules sleep mode.
Power Supplies on the main power supply module, on the I/O modules, and on the CPU
board (i.e. belonging to the plug-in ports) - Turn power supplies on/off according to the user
application request; retrieve power supplies current state.
LEDs Disable LEDs after a pre-defined timeout.
The following system database tables control the power management: CPU Power Supply
[id:233], Main Power Supply 1 [id:234] and Main Power Supply 2 [id:235]. Also, DI and DO
tables can control the power management of DIs and DOs, respectively.
For details on C functions used in power management, see the ACE3600 C Toolkit manual.
Configuration
A number of power management: configuration parameters are defined in the STS site
configuration, including LEDs operating mode, timeout for switching the LEDs off, and size of
the power managers message queue. For details, see Appendix A: Site Configuration
Parameters in the ACE3600 STS User Guide.
12
Power Management
Constraints
Activities on the power supplies have latency (either because they are done through SPI
communication, or because it takes time for the power supplies hardware to stabilize.)
Therefore, a request to manipulate such a power supply is not immediately served. On the other
hand, we dont want the process to wait for a response to the users request. Therefore, such a
request returns immediately and the user must check the hardware indications, (i.e. Get() the
hardwares actual state) and act accordingly.
User requests are mutually exclusive. While the power manager processes a user request, it
disables rescheduling, preventing other requests from being simultaneously served.
13
14
File ID Description
Ladder Application
33
Network Configuration
34
PLC 1
35
Compressed Files
PLC 2
36
PLC 3
37
PLC To Master 1
38
NTP Configuration
PLC To Master 2
41
Feature File
PLC To Master 3
42
Phone Book
43
Sites Table
44
10
'C' Application
45
Encryption File
11
Application Source
49
13
TCP/IP Configuration
50
26
51
27
53
29
56
30
Site Configuration
98
31
100
15
File ID Description
32
File ID Description
IP Conversion Table
In addition to user flash files, the user application can create log flash files (File ID #55)
during runtime.
16
17
18
19
Definitions
Using the FETCH and STORE functions requires the definition of a single-column user table
of integer value type, with the following variables.
Note that the order of the variables in the table is mandatory. The variable names shown in the
table are recommended.
The first three values (Table#, Row# and Column#) represent the coordinates of the required
variable in the database. They must be set by the user before calling the FETCH or STORE
functions.
The FETCH/STORE call return code will be returned in the RetCod variable, as follows:
0 OK
1 spare
2 invalid Z coordinate
3 invalid Y coordinate
4 invalid X coordinate
When calling the FETCH function, the required data will be put in Data0/ Data1 variables
according to the data type (specified by the ColTyp variable), as follows:
If the data is of Bit type (ColTyp=1), the data will be put in Data0 variable according to the
following:
If the data is 0, then Data0=0x0
If the data is 1, then Data0=0xFFFF
If the data is of Value type (ColTyp=2), the data will be put in Data0 variable.
If the data is of Floating Point type (ColTyp=4), the data will be put in Data0 and Data1
variables.
Before calling the STORE function, the data to be stored in the database must be set as follows:
20
If the data is of Bit type (ColTyp=1), the data must be put in Data0 variable according to the
following:
If the data is 0, then Data0=0x0
If the data is 1, then Data0=0xFFFF
If the data is of Value type (ColTyp=2), the data must be put in Data0 variable.
If the data is of Floating Point type (ColTyp=4), the data must be put in Data0 and Data1
variables.
For example, to store the value of fl1 (floating point variable) in the Z0,Y0,X0 coordinates, the
following rungs should be used:
Table#
( MOVE )
Z0
Row#
( MOVE )
Y0
Colmn#
( MOVE )
X0
C
Data0
fl1
#4
Store
( CALL )
Table #
21
Definitions
Data Type
The Event Driven concept is applicable only for Discrete Inputs of Time-Tagged DI (TgDI)
data type.
This data type is similar to the DI data type (see Appendix C: Database Tables and Data Types
in the ACE3600 STS User Guide.) Note that only the important inputs should be defined as
Time-Tagged DI, since this feature is CPU-time and space consuming. By calling the Time
function, a time stamp can also be retrieved and appended to an analog input called via the
SCAN function from the Ladder. This need not be related to a specific event.
I/O Link
The specification of a Time-Tagged DI as Event-Driven is done during I/O Link (accessed
from the Application Programmer). For details, refer to Application Programmer chapter of
the ACE3600 STS User Guide.
During I/O linking, each Time-Tagged DI may be defined in the Event Type column as one of
the following types:
22
TIMETAG for time-tagged COS. Changes are stored in a time tag logger with the time of
occurrence in 1 msec resolution. For further details, refer to the ACE3600 STS User Guide.
EVENT for event-driven COS, described in this chapter.
TAG+EVENT for time-tagged and event-driven COS. A combination of the above two
types.
TmLeas
Day
Month
Year
Hour
Minute
Second
mili-seco
1 byte
1 byte
1 byte
byte
1 byte
1 byte
2 bytes
1-31
1-12
0-99
0-23
0-59
0-59
0-999
Since the tables can hold up to eight columns, all the time's parameters (day, hour etc.) are
arranged in two real type variables. In order to read specific information (e.g.: seconds), the
user should perform LSL (Logic Shift Left) or LSR (Logic Shift Right) for the relevant
variable, TmMost or TmLeas.
The number 0 in the YEAR byte (part of the TmMost) represents the year 1980, the number 1
represents the year 1981 etc. until the number 99 which represents the year 2079. (e.g.: 15
represents the year 1995).
23
The system can simultaneously handle up to 150 events and timers. If there are more than 150
events/timers, the EvOvfl flag of the Reserved Flags table (one of the System Tables), will be
set to 1. In this case, it is recommended to clear the events queue (by calling the StEvnt
function), and performing ordinary scan.
The system can set timers for up to 10 seconds. If no event is read during this period of time,
the timer will be turned off, and the EvOvfl flag will be set to 1. It is the user's responsibility
to reset this flag to 0.
For operations that require delay, the RTU provides the SetTmr function. The end of the timer
is regarded as an event.
Note that in systems with I/O expansion a certain delay is involved from the time that an event
occurs in an I/O expansion frame until it is available to the GtEvnt function. See the Timer
event main frame delay time parameter in the Timer Event section of Appendix A: Site
Configuration Parameters.
SetTmr to start a timer after an event. The termination of the timer is also regarded as an
event (this timer does not depend on the Scan time). The value of the timer should be set in
the ___Val variable (in x10 msec).
The following rungs provide examples that cover all aspects of the Event Driven mechanism.
25
(1)
GtEvnt
( CALL )
(2)
__Typ
(3)
__Tbl
Procs1
( JSP )
=
#0
__Typ
(4)
#9
__Tbl
Procs2
( JSP )
=
#0
__Typ
(5)
#11
__Tbl
Procs3
( JSP )
=
#0
#13
As part of the MAIN process, the above rungs check that an event has occurred, and fulfilling
certain conditions, activate appropriate subprocesses. The above rungs are described below:
Rung 1:
The StEvnt function is called with a parameter of 2 to enable the Event Driven
mechanism. It is recommended to put this rung in the Init process.
Rung 2:
The GtEvnt function is called; the system retrieves an event from the event queue
into the PRMEVENT table, including the event type, table number, column
number, row number, and data of COS.
Rungs 3-5: These rungs check the ___Typ variable and the affected table number; if ___Typ
is not 0 (meaning that there is an event in the queue), the system jumps to perform
a specific process according to the table number. For example, in rung 4 the
system jumps to the Procs2 subprocess since the table number is 11.
The rungs below describe the use of the timer function of the Event Driven mechanism.
26
(1)
__Typ
(2)
Inp2, I
Inp1, I
/
Send2C
( JSP )
#1
Inp2, I
Inp1, I
__Typ
Inp1, I
Inp2, I
Inp1, I
Inp2, I
(3)
__Val
( MOVE )
#30
#1
__Typ
SetTmr
( CALL )
Send2C
( JSP )
(4)
#2
( RET )
(5)
Rung 1:
Rung 2:
Rung 3:
Rung 4:
If the event is caused by a timer (___Typ=2), the system jumps to the Send2C
subprocess to send the current status of Inp1,I and Inp2,I to the central.
Rung 5:
In the MAIN process, you should add appropriate rungs to perform a loop, that checks if there
are additional events in the queue.
27
To obtain the date and time, decode TmMost and TmLeast, as follows (provided that TmMost
and TmLeas are not zero and contain date/time information to be decoded):
Step 1. Define a set of user variables, as illustrated below. Variables 0 through 6 will get the
date and time components; variables 8 through 11 are auxiliary variables:
Data type: Integer Value
Ind
0
1
2
3
4
5
6
7
8
9
10
11
Name
Myear
Mmonth
Mday
Mhour
Mmin
Msec
Mmsec
(int)
Value
Mv1
Mv2
Lv1
Lv2
Mv1, Mv2 (for TmMost) and Lv1, Lv2 (for TmLeas) must be consecutive.
Step 2. Define the following constants:
Data type: Int Constant
Ind
0
3
4
Name
#4
#255
#8
Value
4
255
8
28
Mv1
TmMost
#4
Lv1
TmLeas
#4
Rung: r6
Mday
( MOVE )
Mv1
Mday
( LSR )
#8
A
Mmonth
Mv1
#255
MYear
( MOVE )
Mv2
MYear
( LSR )
#8
A
Mhour
Mv2
#255
Rung: r7
29
Mmin
( MOVE )
Lv1
Mmin
( LSR )
#8
A
Msec
Lv1
#255
Mmsec
( MOVE )
Lv2
Rung: r8
30
Fast Events
In order to execute the control program defined in the user application, the RTU performs all
functions written in the Ladder Diagram, one after the other. This is called a scan. After a
certain period of time, the RTU repeats this procedure. The period between two scans is called
scan time. During the scan, the RTU can respond to events or status changes in the devices
in the field, represented by database variables and values.
When an application requires a faster response to events than the scan time permits, fast event,
interrupt-driven triggers can be defined. Such a trigger activates a high priority fast process
which can react quickly to the physical change.
Events Triggers
The elements which can trigger fast events are:
Digital Inputs
Pushbutton PB2
Delay Timers
Note: Analog inputs cannot be used to trigger fast events. If the application includes analog
inputs which require an immediate response, the user application itself should sample the
analog values frequently and activate the immediate process if needed.
31
Fast Events
Proc
Trig
P1
T
D
S
Proc
Trig
P1
When enabling a trigger from the ladder application (using the TEN operator), make sure
to add a condition to the ladder rung.
When enabling a pushbutton or DI trigger, the call to TEN should not be in a loop,
because once the trigger has been enabled, it is meaningless to enable it again.
Generally, the ignition of a fast event trigger is preceded by the relevant logic in the
ladder. Ignition of a delay trigger does not necessarily include logic before triggering a
process.
If there is a jump from the fast process to another rung, the compiler will produce a
warning, because this might lead to an infinite loop.
T
E
N
Proc1
FE_DI_COS
DI,x
Proc1
FE_PB_UP
PushB2
Fast Events
T
E
N
Proc1
FE_DELAY
#10
Fast Events
In the event that a process monopolizes system resources and chokes the unit, a dump is made
to the error logger before the unit restarts. Once the unit has started up again, check the error
logger to identify the problem. Focus on the lines after Reboot handler: until
prv_userrom_exec. The figure below depicts such an Error Logger entry.
If, for some reason, the system is unable to initialize the fast event feature, the first line in the
F_EVNT level 0 diagnostic will indicate that Fast event feature (F_EVNT software device)
disabled by system. Contact product support group.
Fast Events
35
Standby CPU the CPU that does not control the I/O modules
The ACE3680 RTU can be configured with redundant CPUs to ensure that RTU operation
(monitoring, control, etc.) continues uninterrupted in the event of a failure. Two CPUs are
located in the RTU frame, one primary and one secondary. One CPU is active and controls the
I/O modules, while the other is on standby. The active CPU can update the standby CPU (date,
time, database tables, etc.) in order for the two to remain synchronized. The standby CPU
continuously monitors the active CPU to make sure it is operational. If the primary CPU fails
(e.g. power falls below a critical level) or if the CPU is restarted due to configuration/
application download, the secondary CPU becomes active and controls the I/O modules. When
the failed CPU is repaired or replaced, it becomes the standby CPU.
The two peer CPUs share a common (logical) site ID. In addition, each has a private ID (site
ID 1.) These IDs are visible in both the site view and system view. When a site with
redundancy is created, all three IDs must be available. If one of the IDs is in use, the common
site ID cannot be used. Because a site ID must be between 1-65287, the common site ID
cannot be less than two.
Note: As with non-redundant RTUs, if you change the site ID in the STS, you must also
change the site ID in the RTU using the Downloader.
The two CPUs are connected via the RTU motherboard using an internal Ethernet link. This
link is defined in the STS between the internal redundancy Ethernet port (INTR1) on each peer.
The MDLC link name must be identical for both peers and unique for each set of peers within
the system. The INTR1 port is not displayed in the STS unless redundancy is configured. Its
parameters are equivalent to those of a Static LAN port.
When a redundant site is added to the system, new entries are added to the generic network
table for each redundancy peer, with the private ID as the Site ID. The list of links, including
the IP link for ports INTR1, will appear.
Note: IRRInet-ACE RTUs do not support RTU redundancy.
In the figure below, the two peer sites are attached and marked with a yellow circle, half of
which marks each peer. Line 11 is the MDLC link used to connect the two internal ports.
36
Site ID
37
Redundancy parameters (when both peers exist. When only the secondary site is defined
the redundancy parameters can be changed.)
For more information on configuring sites using the STS, see the Operation chapter of the
ACE3600 STS User Guide.
ERR_NULL (0)
ERR_BUSY (50)
ERR_NOT_FOUND (62)
ERR_READY (51)
ERR_FORMAT (69)
ERR_TYPE (64)
ERR_DATA (58)
ERR_EMPTY (52)
ERR_SIZE (54)
ERR_MEMORY (79)
ERR_PORT (56)
Communication failure
ERR_ERROR (49)
Important: The C application user should verify that the initial copy to memory succeeded
and then that the copy from memory to the peer CPU was completed successfully.
In the user C application, the user can deactivate the active CPU, which will cause the
standby CPU to become active.
When a user application is attached to both the primary and secondary CPUs, the I/O link and
KLV/PDV values must be assigned to each CPU individually. (When I/O link and KLV/PDV
are assigned to one peer, they are not automatically assigned the other.)
To enable routing through both the active and the standby CPUs, the generic network table
includes the primary and secondary private IDs, and does not include the common site ID. If
you want other RTUs to route only via the active CPU (the common site ID), the two
redundant peers must have identical ports and links, and the network table must list the
common site ID only. In this case, create a copy of the generic network table and replace the
two private ID entries with one common site ID (with the same identical link/s as before.) The
private IDs must be deleted from this copy of the network table. Download the modified
network table to any RTUs which will route using the common site ID.
IMPORTANT: The network table downloaded to the redundant peers themselves must include
the private IDs.
Note: An RTU with the Reserved flag Discom = 1 behaves the same as a standby CPU.
Data frames routed using the redundant RTUs common site ID are always relayed by the
active CPU, if the common ID is defined in the network table.
The PDV and KLV Values in the both CPUs should be the same.
41
Network Configuration
The Network Configuration program is used for defining the communication nodes
(interconnection points between two or more links) in the network. The program defines the
networks structure; there is no need to define all RTUs, only the nodes in the network. The
communication protocol uses these definitions for automatic routing of the packets through the
network.
In simple networks, such as one FIU connected to one communication link, it is not necessary
to use this program (see the Communication Network section in the ACE3600 STS User
Guide).
The RTU and FIU ports defined as Computer port, which serve as connection to the STS or
centrals, are not considered as links in the network but as local ports.
A network configuration is stored in a file. The network configuration can be loaded into the
RTU or FIU together with the application. During application loading, the user is asked to
provide the name of the network configuration file.
The same network configuration file is used for all the sites in the system and also may be used
in other networks that have the same structure. The network configuration must be loaded to
all sites in the system to enable each site to route the packets through the network.
When additional sites are to be added to the network, it is not necessary to change the network
configuration definitions since Network Configuration defines only the nodes in the network.
All you have to do is to define the main communication port of each site, via Site
Configuration, and to connect it to one of the network links, using the logical (symbolic) name
of the link.
The network table is generated automatically when using the STS to set up a system. The STS
Network Manager can be used to create additional network tables based on the specific
requirements of the system, and to associate those user-defined network files to the relevant
RTUs in the system.
Network Configuration
When a data link fails to acknowledge transmission, all network paths beginning with it are
marked as fail in the network data bank. The failed link can be restored to OK status if
another transmission happens to succeed. Another mechanism exists, whereby the network
performs periodic checks on failed links and restores them to OK status when an
acknowledgement is received. When this mechanism is disabled, the failed link is considered
to be restored after a specified period of time.
RTU 1
RTU
101
RTU 2
L2
RTU
100
PSTN
RTU 3
RTU 4
RTU 5
.
.
RTU 99
Routing over Direct Link is possible with ACE3600 and the STS, and with the later versions of
MOSCAD and the Programming ToolBox. If you upgrade older legacy applications which try
to transmit over alternate links, these should be modified to prevent redundancy.
When RTU101 tries to transmit to one of the RTUs (1-99), the routing is actually performed by
RTU100. The behavior of the routing in the system, when one of the links to the designated
RTU is failed, is exactly as described in Routing over Alternative Direct Link above.
43
Network Configuration
Network Configuration
than the maximum of link retry timeouts (TX to failed RTU parameter) defined for all of the
RTUs ports and the ports of neighboring RTUs.
The behavior of broadcast frames differs from that of other communications. A failed
broadcast frame does not cause the Remote Failed Link Table to be updated. A failed
broadcast to Site ID 0 does not seek an alternative path. A failed broadcast distribution to other
nodes where the ultimate destination is Site ID 0 does seek an alternative path.
This feature is intended to work in a simple loop shaped network. Using it over a complex
multi-loop network may result in communication performance degradation, due to the heavy
communication required to maintain the Remote Failed Link Table information.
IMPORTANT: When setting this feature, all RTUs in the system must have a firmware
version that supports this feature.
Note: If the size of the Remote Failed Links table is increased substantially, you may need to
increase the Stack size of application manager task parameter in the site configuration in the
Session category of the advanced parameters.
Network Configuration
When a single local radio zone link fails, the system will not necessarily find another path to
the destination site via the radio zone link. For example, in the figure below, if Site 100 fails to
transmit to Site 200 via RADIO1/1, the system will not consider rerouting via RSlink3 to Site
101 and from Site 101 to Site 200 via RADIO1/1 as an alternative link.
Therefore, it is important to create more than one radio zone between sites, as shown below.
46
data modem/radio over PPP. For this purpose an RTU (with packet data radio/modem) is
needed with RS232/RS485 to connect them.
Note: Although the ACE3600 RTU has Ethernet ports, it does not have the IP Gateway
functionality for connecting to a SCADA, nor can it be using with the EPIB Interface for that
purpose. If needed, use the IP Gateway instead.
Multiple IP Ports
The user can specify more than one MDLC over IP port in ACE3600. This depends on the
media used, if Ethernet port can be set as Static LAN, or DHCP and if port is RS232 port can
be set as PPP. Each port is assigned its own Link ID. The IP Conversion Table includes a link
ID column which enables the same ACE3600 site ID to appear several times, with a different
link ID and appropriate IP address.
In some cases, it is necessary to have more than one link ID per MDLC over IP port. For
example, if RTU 1 has a single Ethernet MDLC over IP port, and communicates with another
RTU that has two (or more) MDLC over IP ports (Ethernet or PPP), LINE1 and LINE2. In this
case RTU 1 must have its MDLC over IP port with two link IDs: LINE1 and LINE2. This will
enable direct communication with RTU 2 LINE1 and RTU 2 LINE2 ports.
The enhanced IP conversion table also supports the user of a host name instead of a numeric
Ipv4 address (IP address). In order to use host names, the operator must support this in the
network DNS Server, and the user must specify them in the appropriate port configuration.
The IP conversion table is dynamic, which means its numeric addresses are automatically
learned/updated in runtime, for example when a new RTU is added, or an existing one changes
its addresses. In some cases, such as dynamic addresses of RTUs, there is no need to download
that table to FEP, simply because RTUs addresses are updated when they transmit to the FEP.
In this case, it is recommended that the user application perform these transmissions
periodically.
Note: The IP conversion table learns only a numeric IP address. Host names of other RTUs are
never learned.
49
Dynamic IP Address
Many wireless networks do not allocate a fixed IP address to a PPP modem such as the GPRS
modem. For the FEP to communicate with the RTU it must know its address or host name.
Since these networks do not provide a name for each modem, there is no option of setting them
in the FEP beforehand. In this case, the FEP should not be assigned an IP conversion table
with that link ID (port). The RTUs should be associated with a table which has the FEPs IP
address. If the network operator assigns a host name to the FEP instead of a numeric address,
this can be set in the IP conversion table. When the RTU detects that its modem is connected,
it will notify this address, the FEP, of its new IP address, thus updating its table in runtime.
Since this process does not guarantee that the FEP will be updated, it is highly recommended
that user application periodically send a message to the FEP. For example, if the user
application expects an interrogation every two minutes from the FEP, and it has not received
that, it should send a message to the FEP. This will update the RTU address in the FEP.
MDLC via Standard modem (e.g. GPRS g18 data modem.) See MDLC over Standard
Modem Setup for configuration details. A modem configuration file must be attached to
the site and downloaded to the RTU when using this connection.
MDLC via Tetra radio. This is similar to Standard modem. See MDLC over Tetra Setup
for configuration details. When using a Motorola radio (e.g.MTM700), no modem
configuration file needs to be downloaded.
MDLC via Null modem. This is suitable for direct cable connections over PPP with
devices such as Terminal Servers, wireless modem, etc. Depending on the modem used
you may or may not need to download a modem configuration file.
MDLC over ASTRO IV&D. (e.g. XTL5000) See MDLC over ASTRO IV&D for
configuration details. When using the ASTRO IV&D (Integrated Voice & Data)
connection, no modem configuration file needs to be downloaded.
Static IP address mode. See MDLC over LAN/Ethernet for more information and Static IP
Address Configuration for configuration details.
Dynamic (DHCP) mode. See MDLC over LAN/Ethernet for more information and
Dynamic Configuration over IP using DHCP for configuration details.
51
Single Repeater
IP Site Connect
52
Note that it is possible to change the MDLC communication settings without stopping the
MDLC communication driver, by right-click on the MDLC communication driver icon in the
system tray, and selecting Change Settings.
For more information on using the STS Communication Setup and Phonebook Editor/Dialer,
see the ACE3600 STS User Guide.
where Connection Type is PPP and Connection Mode can be any of several
options, such as Tetra, iDEN, Standard Modem, etc.
For IP connections via LAN, the port type will follow the form of:
10/100 BT, Address Mode, Connection Type, Connected To:
where Address Mode is either DHCP Client or Static LAN, Connection Type is Ethernet
and Connected To is LAN.
Several advanced parameters will be set in accordance with the port configuration. The
parameters for MDLC over IP are described in detail under RTU Site Configuration for the
MDLC over iDEN option below. For changes to these parameter settings for other
variations, see the specific setup section.
2. Define the IP conversion table using the IP Conversion Table Manager and attach it to the
site as an add-on file.
3. Where a modem configuration file is used, attach it to the port as an add-on file.
4. Download the site configuration and IP conversion table, the modem configuration file,
where relevant, the network configuration, and, if necessary, applications, etc. to the RTU.
5. Verify that the RTU can successfully communicate over IP via the radio/modem.
link layer that will guarantee a best effort delivery, and thus avoids overloading the channel
with excessive traffic.
A site is paged by sending it a poll request and awaiting a poll reply. During this time, the
RTU can continue to transmit to other sites (and receive transmission from other sites). If the
site responds with a poll reply, or any other MDLC data, it is considered as reachable, and all
pending transmissions are sent to it immediately. Further transmissions will be sent to it as well
without paging until the site is declared as failed.
If an ICMP Destination Unreachable message is received or if the site does not respond to
paging for a configurable poll interval, it will be polled again for a maximum number of polls.
If there is still no response, the site is considered to be failed, and the network layer is notified
so any pending transmissions can be redirected to an alternative route. If subsequent
transmissions are to be sent to the site through an MDLC over IP port, paging will be
performed again before actual transmission takes place.
The Site Paging mechanism can be enabled or disabled.
When using modem devices iDEN, Tetra, Standard and Null modem, all sites are reset to
unknown state when disconnecting and reconnecting the modem/cable to RTU. For ASTRO
IV&D because no DCD exists, the RTU detects the lack of signal from the port several seconds
(40 by default) after the data cable is disconnected, or the radio is powered off. As a result,
following this operation, paging will be performed before a transmission is sent.
With non-modem devices, such as MDLC via Ethernet, reconnecting cable will not cause
paging to be performed.
Three parameters (Check Alive timeout, Poll interval , and Maximum number of polls) have
been added to the Advanced Link layer for paging purposes and are described in detail in the
Advanced Link Layer section under MDLC via iDEN. For each variation of MDLC over IP,
the parameter setting may vary.
54
SCADA
Central
STS
Ethernet 1
LINE 1
RS-232
IP
Gateway
STS
IP
Network
Ethernet 2
Ethernet 3
10BaseT
10BaseT
RTU-IP1
RTU-IP2
10BaseT
RTU-IP3
RS-232
STS
on Ethernet
on-board Port
on Ethernet
Plug-in Port
With SCADA systems, the ACE3600 RTU can be connected to Ethernet/LAN as an FEP (FIU)
for a SCADA, and an RTU. It communicates with MDLC over IP between FEP/IP Gateway
and RTU. The IP Gateways unique functionality provides an API over TCP/IP API, for the
SCADA PC. It provides the SCADA with the current values of the RTU tables and with the
events (Bursts) that are associated with each entity. The ACE3600 does not have that
functionality built-in and requires an IP Gateway.
Unlike IP Gateway, the ACE3600 can be connected to several Ethernet connections. They can
reside on the same or on different network subnet masks, and are distinguished from one
another by a link name.
A number of connection methods are available when configuring an Ethernet-based RTU port:
1. Static IP address The user sets the IP address within the configuration of the device in the
STS. To use this method, follow the instructions for configuring an RTU port in the
Operation chapter in the ACE3600 STS User Guide. All DHCP parameters will remain at
default values.
With static IP address mode, the user is required to set the link ID, IP address, subnet mask
and default gateway. If DNS or NTP servers are required, these must be defined as well.
DNS servers are only required if this port is to be accessed via a host name rather than a
numeric IP address. In this case the operator assigns a host domain name to the FEP or
RTU. The IP conversion table must include the domain name well. If an NTP server is to
be used to obtain the time, the numeric IP address or domain name of the NTP server must
be defined.
2. DHCP-supplied reserved IP address For every ACE3600 RTU Ethernet port, an IP
address will be reserved within the DHCP server. The link between the RTU and the
reservation will be based on unique ID. In the DHCP Server, set the unique ID. The
55
Range: 000.000.000.001-255.255.255.254
IP address of the RTU Ethernet port. For information on this and other IP addresses in the
configuration, see your network administrator.
Default Routing IP Address
Range: 000.000.000.001-255.255.255.254
This serves as the router from the network address to the remote IP network. The IP network
mask of this address should be the same as the Self IP address. For example, if the IP network
mask is 255.255.255.0 and the Self IP address is 155.9.199.235, then 155.9.199.1 is a valid
default routing address. All IP datagrams transmitted to remote networks outside of
155.9.199.xxx will be directed to 155.9.199.1 router.
This parameter is optional, in case IP Conversion Table has addresses beyond 155.9.199.xxx
for that ports Link ID. If all RTUs, FEP and IP Gateway reside on 155.9.199.xxx it can be
0.0.0.0.
IP Network Mask
Range: 000.000.000.000-255.255.255.255
This parameter is required and determines the network mask along with Self IP address.
56
If a default router was specified, its network IP address (the logical AND of its IP address and
IP network mask) should be the same as the network Self IP address. For example, if the Self
IP address is 155.9.199.235 and network mask 255.255.255.0, the default router should be
155.9.199.xxx (for example 155.9.199.1).
DNS Servers
NTP Server
Ethernet ports of the ACE3600 RTU can be configured dynamically using DHCP. Each one of
these ports can be configured as a DHCP client.
When such a port is configured as a DHCP client, it will receive several vital IP parameters
from the DHCP server such as IP address, Subnet mask, Default router, etc.
57
Links:
DNS Servers
A user may enter three DNS servers, though this step is not
necessary since it is learned from DHCP Server. Note also
this is only required when using host names for this
specified link name in the IP conversion table.
NTP Server
58
Range: 1-65535
Default: 2002
This number is common to all RTUs and IP Gateways
connected to this link. This number identifies the MDLC.
This is a UDP port number and the provider should be
consulted.
It is important that this number not be in use as specified
by the TCP/IP standard RFC0960.
Enable Sync
Range: Disable/Enable
Default: Disable
If this parameter is Enabled, this port can send an MDLC
Sync to other RTUs, and receive an MDLC sync.
If this parameter is Disabled, this port does not send an
MDLC Sync, and ignores received sync frames. It can
however forward sync words that were initiated from
other Link IDs, or from the STS.
It is recommended to use the NTP protocol instead for
time settings.
Range: Disable/Enable
Notify IP Address
when connected
Default: Enable
When enabled, if an RTUs IP address is changed or
obtained from a modem, the RTU will send a message to
update its IP Address in all sites.
Note: These messages are sent one after the other, and it
is not guaranteed they will be delivered and accepted.
Range: Disable/Enable
Enable routing on
MDLC over IP port
Default: Disable
When enabled, an RTU or FEP can route back MDLC
over IP packets received that were destined for a different
site ID. When disabled, an RTU or FEP ignores packets
received which are destined for other sites.
This parameter allows two RTUs to communicate via this
RTU, and is useful if they have dynamic IP addresses.
Note also that the RTUs need to transmit periodically in
order for their IP address to be updated in its IP
conversion table.
A paging mechanism to each site (peer) in IP conversion table makes MDLC over IP more
reliable. The following parameters have been added to Link layer and are optional. For more
information refer to MDLC over IP Site Paging.
MDLC over IP port
number
59
Poll interval in
seconds
Maximum number of
polls
MDLC over iDEN, which uses IP technology, deals only with the first mode (PD). The other
two can only be used with an external dialup port in the RTU, and do not support direct
communication with another RTU/IP Gateway having an MDLC over IP port. Therefore they
are not relevant to this topic.
In the figure below, the SCADA central and IP Gateway are connected via LAN to iDEN
infrastructure. Each RTU has an iM1000/iM1500 modem connected to its MDLC over IP Port.
A unique IP address is assigned to each RTU according to its modems identifier. All
communication between RTUs and the IP Gateway involves sending datagrams in packets over
the internet (IP). A PC running ACE3600 STS can be connected directly to an RTU or operate
remotely over IP.
SCADA
Central
Ethernet
IP
Routing
Net
LINE 1
RS-232
IP
Gateway
STS
Home
Agent
iDEN
infrastructure
Interface
Router
Base
Station
Mobile
Data
Gateway
LINE 1
iDEN iM1000
Packet Data
modem
STS
RS-232
RTU-A
iDEN iM1000
Packet Data
modem
RTU-B
61
depends on the topology and state of the network. This may be relevant for some applications
involving data sent from one RTU to another.
Currently the iDEN modem can be physically connected to PI1/PI2 or SI1/SI2. Only one
iDEN modem can be used per RTU because its internal IP address is the same.
The Advanced parameters should be set as defined below.
Data Speed
DNS Servers
NTP Server
63
Port Mode
Optional AT command
string
RTS Always On
Number of
configuration attempts
to reset radio/modem
64
Default: 0
Range: 0 to 255.
If not 0 it determines the number of retries to poll the
modem if it does not reply. If retried with no response for
max retries, the data cable to the modem is regarded as
disconnected.
For iDEN leave it 0.
This parameter is intended to be used when no DCD input
signal is provided by the modem.
If a modem configuration file was downloaded, the
pppechosendmaxretry variable overrides this setting.
If a PPP connection type is used, the following optional parameters exist as well but for iDEN
they should be left unchanged. They are intended to support more modems/radios.
PPP echo send
interval [sec]
PPP protocol
compression
PPP address
compression
User name
Default: 0
Range: 0 to 255.
If not set to 0, it determines the time interval to poll the
modem over PPP. If no reply is received within PPP
echo send max retries, it will declare the cable as
disconnected, and start to reconnect with the modem.
For iDEN leave it as 0.
This parameter is intended to be used when no DCD input
signal is provided by the modem.
If a modem configuration file was downloaded, the
pppechosendinterval variable overrides this setting.
Default: Enable
Range: Disable/Enable
If enabled, this configures PPP to use protocol field
compression as defined in RFC1661.
For iDEN leave it enabled.
If a modem configuration file was downloaded, the
pppprocomp variable overrides this setting.
Default: Enable
Range: Disable/Enable
If enabled, this configures PPP to use address field
compression as defined in RFC1661.
For iDEN leave it enabled.
If a modem configuration file was downloaded, the
pppaddrcomp variable overrides this setting.
Set the appropriate user name for connecting to the
modem when performing PPP authentication.
If a modem configuration file was downloaded, the
username variable in the file overrides this setting.
65
Password
Periodic check of
failed RTU
Default group IP
address
Get host by name
using DNS
Range: 0-30
Default: 0 (also disables)
It specifies a period of time in seconds, after which a
failed link will be considered as being back in order,
provided the value of the Periodic check of failed RTU
parameter is set to Disable.
If the Periodic check of failed RTU parameter is enabled,
it specifies the period of time in seconds after which the
Network layer issues a control frame to check the failed
link.
Default: Disable
The network sends a control frame to check whether the
link is still in "failed" status. The frame is issued if the
link has been in "failed" status for the period of time
specified in the TX to failed RTU every <O:DISABLE 030> Min parameter.
Range: 000.000.000.000-255.255.255.255
Identifies Site ID 0 which is used for Group Call on
specific link ID.
Default: Enable.
This parameter enables host name within IP Conversion
Table for the specified link name. If set to Disable, host
names cannot be used within that link name in IP
Conversion Table.
The following parameters are common to all Link names configured for this port.
66
Enable Sync
Notify IP Address
when connected
Enable routing on
MDLC over IP port
Range: 1-65535
Default: 2002
This number is common to all RTUs and IP Gateways
connected to this link. This number identifies the MDLC.
This is a UDP port number and the provider should be
consulted.
It is important that this number not be in use as specified
by the TCP/IP standard RFC0960.
Range: Disable/Enable
Default: Disable
If this parameter is Enabled, this port can send an MDLC
Sync to other RTUs, and receive an MDLC sync.
If this parameter is Disabled, this port does not send an
MDLC Sync, and ignores received sync frames. It can
however forward sync words that were initiated from
other link IDs, or from the STS.
It is recommended to use the NTP protocol instead for
time settings.
Range: Disable/Enable
Default: Enable
When enabled, if an RTUs IP address is changed or
obtained from a modem, the RTU will send a message to
update its IP Address in all sites.
Note: These messages are sent one after the other, and it
is not guaranteed they will be delivered and accepted.
Range: Disable/Enable
Default: Disable
When enabled, an RTU or FEP can route back MDLC
over IP packets received that destined to a different site
ID. When disable, an RTU or FEP ignore packets
received which are destined to other sites.
This parameter allows two RTUs to communicate via this
RTU, is useful if they have dynamic IP address. Note also
they need to transmit periodically for their IP address to
be updated in its IP Conversion Table.
67
Modem configuration
timeout (Sec)
Enable RALP
68
Range: 1- 65535
Default: 0
When specifying a timeout in seconds, the RTU monitors
the delay from the last time anything was received from
the modem (during PPP mode). If this time expires, this
means there is a problem with the modem connection.
The RTU will disconnect and reconnect to the modem.
If 0, this parameter ignored.
Range: 0 to 65535 seconds
Registration life time
Default: 7200
If not 0, this sets an interval in which a connected
radio/modem is deregistered and reregistered for packet
data.
The RTU adds an offset to this number, which is derived
from its site ID, so not all radios are restarted and context
activated at the same time.
If a file was downloaded, this parameter can be
overridden using the regLifeTimeout variable.
A paging mechanism to each site (peer) in IP conversion table makes MDLC over IP more
reliable. The following parameters have been added to Link layer and are optional. For more
information refer to MDLC over IP Site Paging.
Disconnect on idle
timeout sec
69
Poll interval in
seconds
Maximum number of
polls
Range: 1000-4000
Default: 1300
infrastructure to reset parameters in the modem. These changes should only be performed in
coordination with the technical support group.
AT+WS53? Checks the signal quality on a normalized scale (from 0 to 100), where 100 is
the best signal, and <75 means it is poor quality.
The firmware checks the signal quality before attempting to register the modem. If signal
quality is below 75, the RTU will keep issuing this command until getting a better value. If
reasonable quality is not reached within Modem configuration timeout (by default it is 40
seconds), the RTU declares the modem configuration as failed. It will retry to configure the
modem immediately afterwards. If failed for more than Number of configuration attempts to
reset radio/modem times successively, it will restart the modem using the above AT command.
AT+IPR= Sets the modem data speed.
By default, the data speed of the iDEN iM1000/iM1500 modem is set to 19200 to match the
default data speed of the RTU. The firmware automatically sets the modem data speed to the
rate specified by the user for the port.
If the data speed of the RTU port is changed, firmware will change the modem speed
accordingly.
It is recommended that all RTUs operate their modems on the same data speed.
72
SCADA
Central
Ethernet
IP
Routing
Net
LINE 1
RS-232
IP
Gateway
STS
Tetra
Infrastructure
SW MI
LINE 1
STS
RS-232
Tetra
MTP700
radio
Tetra
MTP700
radio
RTU-A
RTU-B
The STS can communicate with remote RTUs over IP using the Tetra infrastructure. The PC
running the STS is connected to the Tetra radio (e.g. MTH500 radio) or to the RTU. For this
73
purpose, the PC should have a Tetra PD installation (as specified in the CPS user manual).
After setting up the connection, the user should run the STS Communication Setup utility,
select Ethernet port and specify in a focal point RTU/IP Gateway IP Address under Local Site
IP Address.
It is important to note that RTU to RTU communication is routed through the infrastructure
LAN system and not directly.
Note that a paging mechanism to each site (peer) in IP conversion table makes MDLC over IP
more reliable. For details, see MDLC over IP Site Paging.
Tetra does not support group calls (RTU-to-RTU broadcasts). To send a frame to a group of
sites, the application should send to each site individually, leaving a short wait time between
each transmission (about 300 milliseconds).
Use the FTN6359A connector (RS232-E+). This will enable the RTU to control DTR of the
radio. Refer to Appendix A of this manual for details on the FTN6359A (RS232-E+)
connector.
The Advanced parameters are the same as described above for general MDLC over IP with the
following exceptions:
Data Speed
74
DNS Servers
NTP Server
The user may enter three DNS servers. Note that TETRA
MTM700 and MTM800 radios do not learn the server
information from the modem, so if host names are used in
the Customer Enterprise Network (CEN)/LAN, the user
should enter this information. On the other hand, most
applications do not have host names in the CEN of
TETRA.
The user may specify up to three NTP Servers. If defined,
they will be polled for the time of day every 2 seconds-17
minutes. Expect a clock offset of around 100
milliseconds. The NTP Server can be the FEP on CEN or
any PC acting as an NTP server that the user set up in the
CEN.
If an FEP is used, and it is not connected to GPS, it is up
to the user to set its clock. Note that NTP servers are
never learned from the modem.
Port Mode
Optional AT command
string
RTS Always On
75
Number of
configuration attempts
to reset radio/modem
Default: 2.
Range: 0 to 255.
If the RTU fails to configure or register a modem, and the
modem supports this feature, it can restart the modem
using AT commands. This parameter determines how
many failed attempts to connect to the modem are
required before restarting it.
If a modem configuration file was downloaded, the
n_failstoreset variable in file overrides this setting.
Default: 7 seconds.
Range: 0 to 255 seconds.
Specify how long to wait after restarting the radio as
above before attempting to configure and register it.
If a modem configuration file was downloaded, the
SetRtsTimeout variable overrides this setting.
If a PPP connection type is used, the following optional parameters exist as well, but for iDEN
they should be left unchanged. They are intended to support more modems/radios.
Default: 0
Range: 0 to 255.
If not 0 it determines the number of retries to poll the
modem if it does not reply. If retried with no response for
max retries, the data cable to the modem is regarded as
disconnected.
For iDEN leave it 0.
This parameter is intended to be used when no DCD input
signal is provided by the modem.
If a modem configuration file was downloaded, the
pppechosendmaxretry variable overrides this setting.
Default: 0
Range: 0 to 255.
If not set to 0, it determines the time interval to poll the
modem over PPP. If no reply is received within PPP
echo send max retries, it will declare the cable as
disconnected, and start to reconnect with the modem.
For iDEN leave it as 0.
This parameter is intended to be used when no DCD input
signal is provided by the modem.
If a modem configuration file was downloaded, the
pppechosendinterval variable overrides this setting.
76
PPP protocol
compression
PPP address
compression
User name
Password
Default: Enable
Range: Disable/Enable
If enabled, this configures PPP to use protocol field
compression as defined in RFC1661.
For iDEN leave it enabled.
If a modem configuration file was downloaded, the
pppprocomp variable overrides this setting.
Default: Enable
Range: Disable/Enable
If enabled, this configures PPP to use address field
compression as defined in RFC1661.
For iDEN leave it enabled.
If a modem configuration file was downloaded, the
pppaddrcomp variable overrides this setting.
Set appropriate user name for connecting to the modem
when performing PPP authentication.
If a modem configuration file was downloaded, the
username variable in the file overrides this setting.
Set appropriate password for connecting to modem when
performing PPP authentication.
If a modem configuration file was downloaded, the
password variable in the file overrides this setting.
Range: 0-30
Default: 0 (also disables)
It specifies a period of time in seconds, after which a
failed link will be considered as being back in order,
provided the value of the Periodic check of failed RTU
parameter is set to Disable.
If the Periodic check of failed RTU parameter is enabled,
it specifies the period of time in seconds after which the
Network layer issues a control frame to check the failed
link.
77
Default: Disable
The network sends a control frame to check whether the
link is still in "failed" status. The frame is issued if the
link has been in "failed" status for the period of time
specified in the TX to failed RTU every <O:DISABLE 030> Min parameter.
Range: 000.000.000.000-255.255.255.255
Default group IP
address
Identifies Site ID 0 which is used for Group Call on
specific link ID.
Default: Enable.
Get host by name
using DNS
This parameter enables host name within IP Conversion
Table for the specified link name. If set to Disable, host
names cannot be used within that link name in IP
Conversion Table.
The following parameters are common to all Link names configured for this port.
Periodic check of
failed RTU
Enable Sync
Notify IP Address
when connected
Range: 1-65535
Default: 2002
This number is common to all RTUs and IP Gateways
connected to this link. This number identifies the MDLC.
This is a UDP port number and the provider should be
consulted.
It is important that this number not be in use as specified
by the TCP/IP standard RFC0960.
Range: Disable/Enable
Default: Disable
If this parameter is Enabled, this port can send an MDLC
Sync to other RTUs, and receive an MDLC sync.
If this parameter is Disabled, this port does not send an
MDLC Sync, and ignores received sync frames. It can
however forward sync words that were initiated from
other Link Ids, or from Toolbox.
It is recommended to use the NTP protocol instead for
time settings.
Range: Disable/Enable
Default: Enable
When enabled, if an RTUs IP address is changed or
obtained from a modem, the RTU will send a message to
update its IP Address in all sites.
Note: these messages are sent one after the other, and it
is not guaranteed they will be delivered and accepted.
78
Enable routing on
MDLC over IP port
Range: Disable/Enable
Default: Disable
When enabled, an RTU or FEP can route back MDLC
over IP packets received that destined to a different site
ID. When disable, an RTU or FEP ignore packets
received which are destined to other sites.
This parameter allows two RTUs to communicate via this
RTU, is useful if they have dynamic IP address. Note also
they need to transmit periodically for their IP address to
be updated in its IP Conversion Table.
Modem configuration
timeout (Sec)
Disconnect on
icmp:netunreach
Range: Disable/Enable
Default: Disable
If set to Enable, connection to the modem/radio will be
terminated by force when getting an icmp:netunreach.
This message specifies that the peer site was unreachable
because of network problems. Sometimes these problems
can be resolved by reconnecting to the modem.
For Tetra, it is recommended to leave it set to Disable.
Range: 1- 65535
Default: 0
When specifying a timeout in seconds, the RTU monitors
the delay from the last time anything was received from
the modem (during PPP mode). If this time expires, this
means there is a problem with the modem connection.
The RTU will disconnect and reconnect to the modem.
If 0, this parameter ignored.
Disconnect on idle
timeout sec
79
Ignore CD
Range: YES/NO
Default: NO
With Tetra radios such as MTM700, no abort sequence is
supported. Abort sequence is a +++ string sent with a 1
second delay before and after, causing the modem to
move into command mode.
Specifying this parameter as NO will expedite connection
to Tetra radio.
Range: Never, Always, When connect
Default: Never.
When connecting to the modem, its CD is constantly
being polled, and if inactive, the RTU will reconnect to it.
This parameter enables the user to bypass the polling by
ignoring CD. Setting this parameter to Always will cause
RTU not to check CD at all. Setting it into When connect
will ignore CD during the PPP connection phase. When
PPP is connected, CD will be polled.
Setting this parameter to Never will always check CD.
Range: 0 to 65535 seconds
Default: 7200
If not 0, this sets an interval in which a connected
radio/modem is deregistered and reregistered for packet
data.
The RTU adds an offset to this number, which is derived
from its site ID, so not all radios are restarted and context
activated at the same time.
If a file was downloaded, this parameter can be
overridden using the regLifeTimeout variable.
With Tetra, a paging mechanism to each site (peer) in the IP conversion table has been added
to make MDLC over IP more reliable. If the parameters below are not visible, they will have
the default values as specified. The parameters are the same as in other variations of MDLC
over IP, but their default values were changed to suit Tetra infrastructure. For more
information, refer to MDLC over IP Site Paging.
Check Alive timeout in
seconds
Poll interval in
seconds
Maximum number of
polls
Range 0-255
Default: 3
80
81
As with Tetra, the FTN6359A connector (RS232-E+) should be used. Refer to Appendix A for
details on the FTN6359A (RS232-E+) connector.
The Advanced parameters are the same as described above for general MDLC over IP and
MDLC over Tetra. Some of their defaults have been changed.
Poll interval in
seconds
Maximum number of
polls
Range 0-255
Default: 3
83
RTU
RSlink1
g18 GPRS
Packet Data
modem
GPRS
infrastructure
LINE 1
g18 GPRS
Packet Data
modem
STS
RS-232
RTU-A
g18 GPRS
Packet Data
modem
RTU-B
A single GPRS modem can be connected to an RTU. Other ports can be connected to other
GSM modems using dialup ports.
GPRS does not support group calls (RTU-to-RTU broadcasts). To send a frame to a group of
sites, the application should send to each site individually, leaving a short wait time between
each transmission (about 300 milliseconds).
84
It is recommended that the operator provide an APN (Access Point Name) for a fixed IP
address and enable one modem to communicate with another over UDP port 2002. If this is
not possible, the following should be done:
1. The assigned FEP must have a fixed IP or host name. Make sure the operator supports
UDP port 2002 from modem to FEP and vice versa.
2. Assign an IP Conversion table to the RTUs with that FEP IP address or host name.
3. In the application, each RTU should transmit periodically to the FEP, so it learns the recent
address (e.g. every 2 minutes.) Or else wait for a timeout and if nothing is received from
the FEP, send it a message.
Since there are no fixed IP addresses, one modem cannot communicate with another. If this is
required, the FEP can be used to route information between modems as follows:
1. Assign an IP Conversion table to the RTUs with the FEP Site ID + Link ID and IP address,
along with all other relevant sites which need to communicate over that GPRS Link ID.
2. In the FEP, enable the Enable routing on MDLC over IP port parameter in the Advanced
link parameters for that Link ID.
The APN defines the security and capabilities set by your provider for your SIM cards.
For MDLC over IP to work it must have a fixed IP Address. Most GPRS APNs change IP
addresses each time the RTU reconnects PPP. Reconnecting PPP is a valid operation and can
be done more than once. In order for other sites to communicate with an RTU using MDLC
over IP, it is mandatory that the RTU receive the same IP Address each time it reconnects PPP.
Therefore, you must request APN having a fixed IP address allocation from your operator.
Note: Each SIM Card has unique identifiers for a GPRS/GSM modem. Placing a given SIM
card on different modems causes the same settings to be retrieved from infrastructure (phone
number, IP Address etc.) regardless of the modem.
Use the STS Add-Ons Manager and Downloader to select the modem configuration file for the
specified port and download the G18.stm file.
RTU Configuration
In the Site Configuration, set up either PI1/PI2 or SI1/SI2 as RS232, Async, PPP. Select
Standard Modem:
85
The Advanced parameters are the same as described above for MDLC over Standard Modem.
86
SCADA
Central
Ethernet
Customer
Enterprise
Network
LINE 1
RS-232
IP
Gateway
STS
ASTRO IV&D
infrastructure
GGSN
PDR
Base
Station
RNG
LINE 1
RS-232
XTL5000 Radio
XTL5000 Radio
RTU-A
RTU-B
STS
87
A PC running STS can be connected directly to an RTU, directly to a radio, or it can operate
remotely over the CEN.
For an RTU or PC to communicate over the air using an ASTRO IV&D radio, the radio must
be context activated, or registered for data, in addition to the PPP connection over RS232
interface. The RTU uses SNMP protocol and sets a value in a MIB variable defined for this
radio. When this succeeds, the radio configuration is completed, and the radio (using the IP
address provided periodically by the GGSN in the infrastructure) is able to receive and transmit
data. If the context activation fails or is deactivated, the RTU causes the radio to restart (power
itself off and on.) Once the radio has been context activated, an RTU (or PC) can transmit IP
frames over the air to the PDR which routes them to the GGSN and CEN.
Certain configuration steps are performed on the radio itself using the CPS and in the
infrastructure using the UCM tool. See the relevant radio documentation for more information.
There are two types of hardware interface between the RTU and the radio: For a mobile radio
such as the XTL5000, the interface is comprised of a radio data cable over RS232.
Note: A PC needs a tool called Data Link Manager (DLM) in order to communicate over the
air.
ASTRO IV&D does not support group calls (RTU-to-RTU broadcasts). To send a
frame to a group of sites, the application should send to each site individually, leaving
a short wait time between each transmission (300-1000 milliseconds depending upon
the communication used.)
Sending frames from one RTU to another when both are connected to radios may not
be reliable, because of the ASTRO IV&D's limited resources. It is recommended to
have an RTU connected to LAN (CEN) that will route the information between them.
The Advanced parameters are the same as described above for general MDLC over IP and
MDLC over Tetra. Some of their defaults have been changed.
As an option, the user can override some of these settings by downloading a modem
configuration file such as XTL5000.stm to the RTU port to which the radio is connected.
Data Speed
If the RTU needs to log into the infrastructure/radio using a user name via PPP connection,
specify the following parameters.
User name
Password
Default routing IP
address
IP network mask
89
Range: 1-65535
Default: 2002
This number is common to all RTUs and IP Gateways
connected to the link. This number identifies the MDLC.
This is a UDP port number and the provider should be
consulted.
It is important that this number not be in use as specified
by the TCP/IP standard RFC0960.
90
PPP protocol
compression
PPP address
compression
Default: 10
Range: 0 to 255.
If not 0 it determines the time interval to poll the radio
over PPP. If no reply is received within max retries, it
will declare the cable as disconnected, and start to
connect with the radio again.
This parameter is needed because ASTRO IV&D radios
do not have DCD.
If a modem configuration file was downloaded, the
pppechosendinterval variable overrides this setting.
Default: 3
Range: 0 to 255.
If not 0 it determines the number of retries to poll the
radio if no reply is received. If no response is received
after max retries, the data cable to the radio is regarded as
disconnected.
This parameter is needed because ASTRO IV&D radios
do not have DCD.
If a modem configuration file was downloaded, the
pppechosendmaxretry variable overrides this setting.
Default: Enable
Range: Disable/Enable
If enabled this configures PPP to use protocol field
compression as defined in RFC1661.
For ASTRO IV&D, leave it disabled.
If a modem configuration file was downloaded, the
pppprocomp variable overrides this setting.
Default: Disable
Range: Disable/Enable
If enabled this configures PPP to use address field
compression as defined in RFC1661.
For ASTRO IV&D, leave it enabled.
If a modem configuration file was downloaded, the
pppaddrcomp variable overrides this setting.
91
Disconnect on idle
timeout sec
Ignore CD
Range: Disable/Enable
Default: Disable
If set to Enable, the connection to the radio will be
terminated by force when getting an icmp:netunreach.
This message specifies that the peer site was unreachable
because of network problems. Sometimes these problems
can be resolved by reconnecting to the modem.
For ASTRO IV&D it is recommended to leave it set to
Disable.
If a modem configuration file was downloaded, the
DisconctIcmpNet variable overrides this setting.
Range: YES/NO
Default: YES
Specify YES if the modem supports an abort sequence, a
+++ string sent with a 1 second delay before and after,
causing the modem to move into command mode.
For ASTRO IV&D radios, this parameter should be set to
YES.
If a modem configuration file was downloaded, the
AbortSeqExist variable overrides this setting.
Range: 1- 65535
Default: 0
When specifying a timeout in seconds, the RTU monitors
the delay from the last time anything was received from
the modem (during PPP mode). If this time expires, there
is a problem with the radio context activation. The RTU
will disconnect and context activate the radio.
If a modem configuration file was downloaded, the
DisconctRxIdleTime variable overrides this setting.
Range: Never, Always, When connect
Default: Always.
ASTRO IV&D radios do not provide DCD signal when
connected, therefore this parameter should Always ignore
CD.
If a modem configuration file was downloaded, the
IgnoreCD variable overrides this setting.
92
Notify IP Address
when connected
Range: 0 65535
Default: 0
This parameter is useful with infrastructure that requires
periodic restart of radio.
If 0, periodic restart of radio is disabled (but can be done
via application). If not 0, it specifies how long the RTU
keeps the radio context activated before restarting, and
then context activates it again.
The RTU adds an offset to this number, which is derived
from its site ID, so not all radios are restarted and context
activated at the same time.
If a file was downloaded, this parameter can be
overridden using the regLifeTimeout variable.
Range: Disable/Enable
Default: Enable
When enabled, once a radio get context activated, the
RTU send a message to update its IP Address in all sites.
Note: these messages are sent one after the other, and it
is not guaranteed they will be delivered and accepted.
The RTU connected to the radio uses the MDLC paging mechanism as with Tetra and iDEN.
An MDLC paging mechanism to each site (peer) in IP conversion table makes MDLC over IP
more reliable. For the IP Gateway and IP Interface connected on the CEN, if these parameters
are not visible, they take their default values as 0, and issue no MDLC paging from the CEN.
For more information, refer to MDLC over IP Site Paging.
Check Alive timeout in
seconds
Poll interval in
seconds
Maximum number of
polls
Range 0-255
Default: 3
The following parameters affect the way the RTU context activates the radio and monitors it
via SNMP protocol. The ASTRO IV&D setup requires an SNMP component to be configured
in order for the radio to context activate (register for data). This is configured in the radio using
the CPS tool and in the RTU using STS.
Context activate radio
Range: Disable/Enable
Default: Enable
When enabled, context activate the radio via SNMP, and
monitor it according to the below parameters.
93
Radio context
activation timeout
94
The USB port configuration is similar to that of other IP ports. The following advanced
physical parameters are specific to MDLC over MotoTrbo.
Number of input buffers <1-1024>
[64]:
The number of buffers for the USB and RNDIS layers to be used for receiving data (the
number of clusters used within the Enhanced Network Device END during reception from that
port.) Reducing this parameter may cause reception loss in extreme cases where the system is
busy. When increasing it, allocate more memory in advance.
Note: If more than one MotoTrbo radio is connected, the first (HU1) port sets the number of
input buffers, and the setting for the second port is ignored.
Number of output buffers <1-1024>
[64]:
The number of buffers for the USB and RNDIS layers to be used when transmitting data.
During transmission to the MotoTrbo port, the IP frames sent are queued one at a time. A
single request transaction is issued, one at a time, per each frame sent to the USB. Once a
transmission has completed, i.e. has been acked by the radio USB device, another one is sent.
(This does not mean that it was transmitted over the air, just pending transmission in the radio.)
This parameter determines the maximal number of frames pending transmission that may be
stored in the RTU. Reducing it may cause transmission failures, while increasing it requires
more memory for storage space.
KeepAlive timeout period (seconds) <0-65535>
[5]:
The interval at which the RTU polls the MotoTrbo radio to check the connectivity status. The
polling is done using the RNDIS and DHCP protocols. If the connection with the radio is
disconnected, the RTU reinitiates the connection to the radio (and the RNDIS and DHCP
protocols) in order to transmit and receive IP via the USB port.
If the interval is set to 0, polling the radio is disabled (not recommended.) Decreasing this
parameter to a non zero value, will cause more frequent polls. Increasing the interval will
reduce the number of polls, but will also delay the disconnect detection and the re-initiation of
the radio connection.
Regardless of this parameter setting, the RTU monitors the USB connection status passively.
96
The Advanced parameters are the same as described above for general MDLC over IP and
MDLC over Standard modem and are therefore not repeated here.
For ACE3600 RTUs, a modem configuration file can be downloaded to the following dialup
(circuit data) port:
RS232, Async, External dialup
The modem configuration file (also called standard modem configuration file) is an ASCII file
with sections in which exact AT commands can be specified for connecting to a modem. Some
environment variables can be set as well to define the exact behavior of the port control
function (dealing with connecting the modem and checking that it remains connected.) This file
also contains special sections for diagnosing the modem using AT commands via STS SW
Diagnostics.
Since several circuit data modems can be connected to RTU, the user should specify for which
port the file is being downloaded: i.e. port PI1, PI2, SI1 or SI2. This is done in the
Downloader utility. Note that for now, only a single packet data modem/radio can be connected
to an RTU.
The same configuration file can be used with different sections for circuit data programming
and packet data programming. Since dialup port (circuit data) and PPP ports (packet data)
configure the modem differently, separate sections have been set for each type: The
ConfigureCD section configures a dialup port, and ConfigurePD configures a PPP port.
For dialup ports only, a dedicated section called ChkVld is used to check that the modem is
operational and able to receive calls.
To enable the user diagnose the modem status, Diag0 to Diag7 sections have been allocated.
These sections are invoked when using the SW Diagnostics level 223 or above. Level 223 is
set for running Diag0, level 224 for Diag1, etc. This diagnostic disconnects the modem
temporarily while diagnosing the modem. For that reason, the dialup port will refuse to
perform this operation while in the middle of a call and returns an error. MDLC Over IP
enables this feature by disconnecting PPP temporarily and turning it back on once the
diagnostics are complete.
$Username=
needed.
$Password=
; PPP password if authentication is
needed.
$AbortSeqExist= 1
; 1 - Modem support abort Sequence
$IgnoreCD= 2
; 0 - Never / 1 - Always / 2 - Ignore CD
when connecting
$DisconctIcmpNet= 0
; 1 - Disconnect modem when getting
ICMP:Net Unreach
$DisconctRxIdleTime= 900
; Disconnect on idle timeout in seconds
(15 min)
; 0 - never disconnect if inactive,
98
$UnsetRtsTimeout= 2000
; Wait time before restart the modem
(unset RTS).
$SetRtsTimeout= 4000
; Wait time after restart the modem
(setting RTS).
$ModemAddress= 0
; Modem/radio address (string)
$ModemVersion= 0
; Modem/radio version (string)
$ModemName= Motorola GSM g18 ; Modem/radio type for diagnotic purposes
$ModemRSSI= -; Modem/radio RSSI
$ToggleRtsCommand= 0
; 1 - Toggle RTS (modem's DTR) at
SetCommandMode
$pppechosendinterval= 0
; PPP Echo send interval in milliseconds.
$pppechosendmaxretry= 0
; PPP Echo send max retries.
$pppprocomp= 1
; 1- Enable PPP protocol compression
$pppaddrcomp= 1
; 1- Enable PPP address compression
$pppmaxmtu= 1500
; PPP Max MTU frame size
$pppauthpro= 0
; PPP Authentication Protocol
0xc023/0xc223
$pppasynctl= 0
; PPP Async Control Char Map
$n_failstoreset= 2
; Number of configuration failures to reset
modem
$max_failedtime= 120000
; If failed to configure for 120 seconds
errorlog
; Applicable for IP and not for dialup modems
$WaitAfterDial= 2000
; 2 seconds to wait after dialup to another
modem
; Relevant for dialup only.
$RetryModemConfig= 0
; Set to 1 if need to retry modem
configuration
; Relevant for dialup only.
$RegLifeTime= 7200
; Registration timeout in seconds
[Prereset]
; Does nothing except for unsetting RTS
; (powers modem's plastic box off)
[Postreset]
; Does nothing except for setting RTS
; (powers modem's plastic box on)
[SetCommandMode]
<><><1>
<+++><><1>
[HangupCD]
<ATH0x0D><>
<ATH><NO CARRIER><4>
<AT><OK><2>
; Wait 1 second.
; Wait 1 second.
;
;
;
;
;
;
[HangupPD]
; **For MDLC over IP**
<0x7e0xff0x030xc00x210x050x020x000x040x590x280x7e><><2> ; Send LCP
; Terminate Request
<ATH0x0D><>
; Send ATH\r. Expect no reply.
<ATH0x0D><>
; Send ATH\r; Expect no reply.
<AT><OK><2>
; Send AT\r; Expect OK reply within
; 2 seconds.
[VerifyParms]
<ATI3><$ModemVersion>
; Send ATI3\r; store reply in $ModemVersion
<AT+CIMI><$ModemAddress>; Send AT+CIMI\r; store reply in $ModemAddress
<AT+CSQ><$ModemRSSi>
; Send AT+CSQ\r; store reply in $ModemRSSi
[ConfigureCD]
<><><5>
<AT&F0><OK>
<ATE0V1Q0X4&C1S0=2><OK>
<AT+CMGF=10x0D><><2>
<AT&W0><OK>
<AT&Y0><OK>
;
;
;
;
;
[ConfigurePD]
<AT><OK><2>
[ChkVld]
; **For MDLC over Dialup**
<AT><OK>
; Send AT\r; expect OK.
<AT+CREG?><+CREG:000 001> ; Send AT+CREG?\r; expect +CREG:000 001
; reply.
[Diag0]
<ATI3><$Diag>
<AT+CIMI><$Diag>
<AT+CPIN?><$Diag>
<AT+CGMR><$Diag>
<AT+CGMI><$Diag>
;
;
;
:
:
:
[Diag1]
<AT+CSQ><$Diag>
<AT+CREG?><$Diag>
<AT+CGATT?><$Diag>
<AT+CGPRS?><$Diag>
<AT+CMGF?><$Diag>
;
;
;
;
;
;
[Diag2]
<ATE1><OK>
<AT&V><$Diag><2>
PPP port
Dialup
Invoked when
Initialize
Starting to configure
modem or when a new file
was downloaded.
Hanging up PPP.
Starting to configure
modem or when a new file
was downloaded.
Hanging up call.
Hanging up call.
Starting to configure
modem.
SetCommandMode
HangupCD
100
Dialup only.
Section Name
PPP port
HangupPD
Hanging up PPP.
VerifyParms
Dialup
ConfigureCD
ConfigurePD
VerifyIPParms
DialPD
Diag0
SW Diagnostics of LIN1L
level 223.
Diag1
SW Diagnostics of LIN1L
level 224.
SW Diagnostics of LIN1L
level 225.
SW Diagnostics of LIN1L
level 226.
SW Diagnostics of LIN1L
level 227.
SW Diagnostics of LIN1L
level 228.
SW Diagnostics of LIN1L
level 229.
SW Diagnostics of LIN1D
level 224.
SW Diagnostics of LIN1D
level 225.
SW Diagnostics of LIN1D
level 226.
SW Diagnostics of LIN1D
level 227.
SW Diagnostics of LIN1D
level 228.
SW Diagnostics of LIN1D
level 229.
ChkVld
Diag2
Diag3
Diag4
Diag5
Diag6
101
Invoked when
PPP only.
Hanging up PPP is invoked
when need to diagnose
modem, or when start to
configure it.
PPP only.
Modem is configured when
it is detected that PPP is
not connected or when
RTU is restarted or when a
new file is downloaded.
Dialup Only.
PPP only.
Modem is configured when
it is detected that PPP is
not connected.
PPP only.
If need to read modem IP
Address via AT commands
such as iM1000.
PPP only.
Modem is configured when
it is detected that PPP is
not connected.
Dialup only.
If fails, modem is
reconfigured.
Section Name
PPP port
Dialup
Invoked when
Diag7
SW Diagnostics of LIN1L
level 230.
SW Diagnostics of LIN1D
level 230.
Section Name
PPP port
Dialup
Invoked when
Prereset
Postreset
Modem disconnection:
4. SetCommandMode section.
102
5. HangupPD section.
This puts the modem into command mode and makes sure the modem is connected to the port
prior to configuring it.
In some modems such as G18, an LCP Terminate Request must be sent. This binary string,
which is part of the PPP protocol, makes sure that the modem disconnects PPP, if it was on.
Therefore this is the first string sent in the HangupPD section.
Note for SetCommandMode: Some modems do not support an abort sequence (a 1 second idle
line, followed by +++ string and another 1 second of idle line.) When a modem is connected
this sequence sets it in command mode, where it can be programmed using AT commands.
However, for modems that do not support this feature, leave section [SetCommandMode]
empty, and set the following variable ToggleRtsCommand=1. This will force the RTU to
toggle its RTS output when setting command mode. Using a proper RS232E+ adaptor/cable
(FTN6359A) will connect that signal to the modems DTR input, causing it to disconnect. For
that to work, the modem must have been configured previously with AT&D1.
Modem configuration:
6. VerifyParms section. Verifies modem identity. This is not a mandatory section.
7. ConfigurePD section.
8. DialPD dialup modem and place it in PPP mode. This cause modem to register within
infrastructure.
Once modem has been configured it is now monitored to maintain that connection. Its PPP
connection is monitored as well as its DCD signal, which shows that it is active. This indicates
that the modem is indeed registered and able to receive and transmit IP over the air. Some
modems do not have DCD. A variable named IgnoreCD can be set to 2 (IgnoreAlways) so the
DCD will not be polled. It is recommended to consult with technical support before using such
a modem/radio.
PPP based modems initiate PPP once you dial into it. Connecting PPP involves actually
registering the modem within the infrastructure. This may take several seconds or up to a
minute. During this time, the port is not considered eligible for transmission and any
transmissions are still held pending in queue. Once PPP is connected, the frames can be
transmitted.
The modem is configured in the following situations:
1. When it is detected that the modem is not PPP connected, or its DCD has dropped;
2. When the RTU experiences a power restart (with or without battery);
3. When the RTU restarts because of a new configuration;
4. When downloading a new configuration file;
5. When diagnosing the modem using modem configuration file; levels 223 and above are
used for that purpose.
In the last three cases, the modem is disconnected and is not configured immediately. When
diagnosing using a modem configuration file, the modem is interrogated using AT commands,
103
and its responses are queued within the MDLC over IP port. Once all responses received,
MDLC over IP port reconfigures the modem as specified above.
Note that if it is done remotely, e.g. over a GPRS network, the diagnostic response may take 30
seconds or more. The user should set the modem configuration timeout to be long enough so
that the response does not get lost. A 30 seconds timeout is a typical delay but it may need to
be extended to 60 seconds.
In the G18.stm file, this section is not empty; if it fails to get an appropriate response from the
modem, it reconfigures modem as specified above.
Command
ATE0
ATV1
ATQ0
ATX4
AT&C1
You may enter the commands in one string, ATE0V1Q0X4&CI&W, where &W implies
saving the above parameters for the next power-up.
It is also possible to configure the modem from the RTU over a dialup port. A modem
configuration file is used to send the appropriate AT commands to the modem. For more
information, see the MDLC over Dialup Modem Configuration.
When several RTUs are connected to the PSTN (Public Switching Telephone Network), as
illustrated below, several configurations are viable as described in the examples that follow.
105
RTU 2
MODEM AT
PORT SI2
MODEM AT
PORT SI1
MODEM AT
PORT SI2
PSTN
RTU 1
MODEM AT
PORT SI1
RTU 3
MODEM AT
PORT SI2
MODEM AT
PORT SI2
MODEM AT
PORT SI1
RTU 4
RTU 5
Note that in the illustrated configurations, as in all the connections over the PSTN, there is only
one link ID. It is the responsibility of the software to decide which line to dial. When two
lines are available, the Port SI1 line has priority.
Update the two RTU 5 telephone numbers and the RTU 3 telephone number.
Any transmission from RTU 4 to RTU 5 will cause automatic dialing from the
first available port (when both ports are available, Port SI1 is chosen) to the
first number on the list. If the first number is busy, or there is no answer, the
second number is automatically dialed. As the connection is established,
information will be transferred from one modem to the other. When no
information is transferred for a period longer than the Hanging up an unused
line by INITIATOR after... Advanced Physical Layer parameter, the line will
be disconnected.
Any transmission from RTU 4 to RTU 3 while RTU 4 and RTU 5 are
connected, will cause automatic dialing from Port SI2. If RTU 4 and RTU 5
are disconnected, then Port SI1 will be selected for dialing.
INT Four byte integer variables representing time or Boolean (true or false) values.
Boolean values are 0 for false and 1 for true.
IP Address Four digit IP addresses in the form of xxx.xxx.xxx.xxx where xxx ranges
from 0 to 255.
107
Usually a variable is set manually in the [initialize] section as explained above. For
example:
$WaitForOk= 2000
sends the AT+CIMI command to the modem and sets the ModemAddress variable to the
modem address in the response.
All variable values can be viewed using the SW Diagnostics level 221 for LIN1L (or LIN1D in
dialup port). LIN1 stands for link ID LINE1. If a different link ID is used, such as LINE7 the
device would be LIN7L or LIN7D.
The FileVersion variable is used to identify the modem configuration file version.
FileVersion=xx.yy, where xx is the file version and yy is the file revision. When the file
is downloaded, the RTU verifies that it supports its version.
The file version (xx) should not be changed unless stated. The revision number (yy) is used to
keep track of your changes to the file. It has no meaning to the modem but it is recommended
that it be increased each time the file is changed. For the first release of this feature, the file
version should be set to 1.0.
Variable name
Meaning
Type
Comment
FileVersion
STRING
The following variables are used when programming the modem. Some of them are PPPspecific. Some are common to both MDLC Over IP and MDLC Over Dialup.
Variable name
Meaning
Type
Comment
WaitForOk
INT
Common to both
MDLC Over IP and
MDLC Over Dialup
WaitForDial
INT
WaitForDiag
INT
Common to both
DTEIpAddr
IP Address of RTU
IP Address
DCEIpAddr
IP Address of modem
IP Address
108
Variable name
Meaning
Type
Comment
GTWYIpAddr
IP Address of gateway
IP Address
DTESubnetMask
IP Address
DTEPrefixlen
Number of 1s (most
significant bits) in subnet
mask, e.g. 16: 255.255.0.0
INT
UserName
STRING
Password
STRING
AbortSeqExist
INT
INT
DisconctIcmpNet
INT
DisconctRxIdleTime
INT
SetRTSTimeout
INT
Common to both
IgnoreCD
109
Variable name
Meaning
Type
Comment
UnsetRTSTimeout
INT
Common to both
ToggleRTSCommand
INT
Common to both
Meaning
Type
Comment
ModemName
Name of modem
STRING
Common to both
ModemAddress
STRING
Common to both
ModemVersion
Version of modem
STRING
Common to both
ModemRSSI
RSSI of modem
STRING
Common to both
The following additional PPP variables are available in the STS configuration. If these
variables were set in a file, their value set in that file overrides those settings.
Variable name
Meaning
Type
Comment
Pppechosendinterval
INT
Pppechosendmaxretry
INT
110
Pppprocomp
INT
MDLC over IP
Pppaddrcomp
INT
MDLC over IP
PPPmaxmtu
INT
MDLC over IP
Pppauthpro
INT
MDLC over IP
PPPasynctl
INT
MDLC over IP
111
Meaning
Type
Comment
N_failstoreset
Number of configuration
failures to reset modem. This
parameter is interpreted
differently in MDLC over IP
than in dialup.
INT
MDLC over IP
MDLC over Dialup
This parameter is in
milliseconds.
INT
MDLC over IP
INT
RetryModemConfig
INT
The following variable is for the [DiagX] section such as Diag0. It instructs the RTU to route
the modem response into the SW Diagnostics.
Variable name
Meaning
Type
Diag
STRING
112
Comment
will issue the AT+CIMI Command and put its response in ModemAddress variable.
Multiple responses can be expected by specifying them inside the braces (of expected
response). For example:
<ATH><(OK)(NO CARRIER)>
; LCP
This string is a binary string comprised of the bytes 7e in hex, ff in hex, 03 in hex etc. It is used
for terminating a PPP session.
113
IP Conversion Tables
The IP conversion table is created in the ACE3600 STS using the IP Conversion Table
Manager. Note that unlike the network configuration, there is no default, and any IP
conversion tables must be created manually. The IP conversion table maps sites in the system
(site ID+link ID) to IP addresses or host names. Each site ID/link ID pair can have one unique
entry in the table, though an IP address can appear in more than one row. A site ID of 0 is
reserved for a group call.
In RS232 PPP and Ethernet DHCP, the IP address is read from the network once it is
connected to the RTU. In Astro IV&D, this is not the real IP address set by the infrastructure;
rather, it is a dummy address configured in the radio via the CPS Mobile Computer IP address
which is (by default) 192.168.128.2. In the IP conversion table do not specify this address, but
the actual IP address assigned by the infrastructure operator. Note: The IP address displayed
by the SW Diagnostics LIN1L level 0 is the dummy address and should not be used in the IP
conversion table.
The ACE3600 IP conversion table format includes a link ID column which allows more than
one port in the same site to be connected to LAN or to PPP. Any legacy MOSCAD RTU or IP
Gateway in the network must defined using its own Toolbox IP Conversion Table utility.
Control
Center
CEN LAN
FEP 100
LINE 1
FEP
10.5.1.xx
LINE 2
Packet Data
Network
192.5.1.xx
Subscriber Radio
2
Subscriber Radio
1
PPP/RS-232
LINE 1
LINE 1
PPP/RS-232
PEI
RTU-B
PEI
RTU-A
LINE 2
LINE 2
LAN
155.9.1.xx
In the example above, two sets of IP conversion tables should be created and the FEPs Table
should be assigned to the RTUs:
FEPs Table:
Site ID
Link ID
114
100
LINE1
10.5.1.160
100
LINE2
155.9.1.17
Link ID
LINE1
192.5.1.161
LINE2
155.9.1.18
LINE1
192.5.1.162
LINE2
155.9.1.19
As another example the IP conversion table can be set with names rather than numeric Ipv4
addresses. In this case make sure these names are the full host names set by your network
administrator. Make sure the DNS Server are either learned (DHCP and PPP) or set them
manually in port configuration (Static LAN). You can check DNS servers in the STS SW
Diagnostics device DNS_CLI level 1. For example:
DNS servers list
---------------*ETH1
10.5.34.2
PI2
10.6.34.2
Link ID
100
LINE1
FEP1.moto.com
100
LINE2
FEP2.moto.com
In this example, LINE2 is Static LAN so the user needs to set the DNS servers of LINE2
network in the LINE2 port configuration of RTU #1 and RTU #2. LINE1 is PPP, so there is no
need to set these servers they are learned from the network automatically.
115
In principle it is recommended to create two sets of IP conversion tables one that will be
assigned to an FEP/IP Gateway on the LAN, and one to all other RTUs which are connected
with the ASTRO IV&D radios. The first will include the above information concerning each
RTU, and the second will have only the FEP/IP Gateway.
For MDLC over iDEN, MDLC over Tetra, and MDLC over Standard or Null Modem, consult
the system provider for the infrastructure relating to the IP addresses.
You can also check the IP Address yourself. After the RTU is configured in the STS, connect
the modem to the RTU, and invoke the SW Diagnostics tool in the Software Diagnostics &
Loggers utility. For a port link ID named LINE1, first run device LIN1L level 101 and see if
the state of the configuration task is Connected and registered. Then run level 0, and see the
RTU IP Address as obtained from the modem.
116
Firewall
The ACE3600 Firewall package enables the user to define a variety of firewall protections.
The package is based on Windrivers firewall package, version 1.0.
Firewall Configuration
The firewall is configured and activated in the ACE3600 STS site configuration per site, for all
IP ports in the site. The user can specify the list of IP addresses to accept, i.e. the list of IP
addresses allowed to pass through this firewall. If no IP addresses are defined, then all
addresses are allowed.
The following attributes are defined for the firewall.
Activate firewall? <Disable/Enable>
[Disable]:
[100]:
The MAX size of ICMP Echo (ping) allowed. A ping packet with a bigger size will be ignored,
no response will be sent back.
Address List
The list of IP addresses allowed to pass through this firewall. If no IP address is defined, then
all addresses are allowed. To add or remove addresses from the list, click on Address List. To
append a line, click on Append Line. To remove a line, click on Remove Line.
To save the list, click on OK.
If the firewall is active, all UDP/ TCP ports will be blocked (e.g. telnet, http) except for the
following:
DHCP port
DNS port
MDLC port (UDP 2002)
NTP port
MODBUS port (TCP 502)
Expansion TCP connectivity and data ports (configurable, by default 57001, and 57002)
Expansion UDP discovery port (57001, not user configurable)
Timer event (UDP 57003)
117
Firewall
Manually enter the IP addresses of the expansion frames and main frame (as described in
I/O Expansion Configuration above.) OR
Make sure that no address ranges are defined in the firewall Address List (default) and the
firewall will allow all IP communication.
When you save the site configuration in a system with I/O expansion, the warning message
below will be displayed under the following circumstances:
At least one expansion is defined in the site configuration OR Automatic I/O Recognition
is enabled (i.e. the Enable auto I/O modules recognition at startup, field is checked in the
sites I/O tab.)
The firewall Address List does not include the full range of IP addresses (for thirteen
expansion frames and the main frame.)
This message prompts you to define the IP addresses of expansion frames in the firewall
Address List.
If you want the STS to add the missing IP addresses (based on the address calculation
described in I/O Expansion Configuration above), check the first option and click OK. All
addresses will be added, even if not all thirteen expansion frames are defined. The IP address
of the main CPU will be added as well. (0.0.0.0-0.0.0.13 for the default IP address) If less
than thirteen expansion frames are defined for the system, the range can then be modified
manually to include only defined frames.
118
Firewall
If you want to add the desired address range(s) manually, check the second option and click
OK. Add the IP Address of the main CPU to the list (as described in I/O Expansion
Configuration above) as well as all configured frames. If the range in the IP address list is less
than thirteen addresses (i.e. the system contains less than thirteen expansion frames), be sure to
check Do not ask me again or you will continue to receive the message window whenever
you save the site configuration.
To cancel the operation, click on Cancel. The save operation will be aborted.
If the expansion frames are subsequently deleted from the site configuration but the firewall
Address List still contains the IP address range of the expansion frames, the following warning
message will be displayed (when saving the configuration) to remind the user to delete these
addresses from the list. Click on OK and then remove the address ranges from Advanced ->
Firewall -> Address List.)
If you choose to leave these IP addresses in the list, check Do not show this message again
and click on OK. Otherwise, you will continue to receive this message.
For more on IP addresses and configuration of expansion frames, see the I/O Expansion
Configuration section above.
119
RTUs in different time zones, and better accuracy than the MOSCAD MDLC legacy
synchronization. Note that by default, the ACE3600 uses MOSCAD MDLC legacy
synchronization (to support IP Gateway and MOSCAD RTUs) which does not include the
time zone and password features.
Note: An extended time synchronization of two RTUs, where only one is configured for
time zone, will proceed as if both RTUs are in the same time zone.
The RTU clock can be synchronized during runtime using a number of methods. Before
synchronizing the clock, make sure that the appropriate parameters have been configured
properly. (See Time Parameter Configuration below.)
User Time Control Actions
STS Date & Time utility From the STS, the user sets the RTU date/time to the PCs
date/time (which is limited to seconds accuracy.) For information on using the
Date & Time utility, see the Operation chapter of the ACE3600 STS User
Guide.
STS Sync utility From the STS, the user instructs the local RTU to synchronize (in
milliseconds accuracy) the date/time of other RTUs attached to one or all links.
It is recommended to synchronize all links, so that the entire system has the
same date/time. For information on using the Sync utility, see the Operation
chapter of the ACE3600 STS User Guide. Note that MDLC dialup links do not
support synchronization.
User Application
- The user application (ladder or C) can synchronize RTUs on one or all links
using the Sync function. It is recommended that an RTU with a reliable clock
source synchronize all RTUs in the system once per day to correct clock drift.
The requirement for legacy MOSCAD RTUs to synchronize RTUs at least once
every 48 days is not relevant to ACE3600 RTUs. However, ACE3600 has a drift
of 30 ppm which is 2.6 seconds per day if not connected to an NTP server and/or
GPS receiver. The worst case is a drift of 1.8 milliseconds per minute, or 18
milliseconds per 10 minutes. Typical tests shows better results at 1 millisecond
per 2 minutes, or 5 millisecond per 10 minutes. The interval of sending a time
sync, is proportional to that clock offset/accuracy sending a sync every 2
minutes assures a 1 millisecond offset typically.)
For information on the Sync function, see Appendix B: Ladder Diagram
Language in the ACE3600 STS User Guide. For information on the
MOSCAD_sync(), MOSCAD_datetime_syncall() C services, see the C
Toolkit for ACE3600 RTUs User Guide.
- When the user application (ladder or C) updates the Time & Date database
system table, it also changes the RTU time and date. For more information on
the Time & Date database system table, see Appendix C: Database Tables and
Data Types in the ACE3600 STS User Guide.
- The user can update the same Time & Date database system table
(HH:MM:SS) using the Application Programmer database monitor function. In
this case, synchronization is direct (no time zone aspect.) For information on
121
Notes:
1. When obtaining the time from system time control actions (GPS receiver
and/or NTP server) and the time is valid, the ClockValid system flag in the
Reserved flags system table is set to 1. When this flag is set, all user time
control actions (e.g. Date & Time command, Sync command) are ignored.
2. An RTU or FEP connected to a GPS receiver and/or NTP server, can
synchronize other RTUs either from the ladder application Sync command,
or using STS Sync operation. Note that for IP media this is disabled by
default, and is not recommended, but for non-IP media such as radio or
RS485 it is valid.
3. PC hosts, NTP servers, and GPS receivers operate on UTC time (GMT
time zone). If it is necessary to us the local time set this time zone in the
Timezone offset in minutes advanced parameter in the STS site
configuration.
If the synchronizing RTU is in a different time zone than the RTU being synchronized and
uses extended time sync,, the system will adjust the time accordingly; the receiving RTU
will add the time zone of the sender to the global time (GMT) and use this. If only one of
the two RTUs involved is configured for time zone support, the synchronization will
proceed as if both sites are in the same time zone.
Note: A legacy MOSCAD RTUs is treated as an RTU which is not configured for time
zone support.
122
Time Synchronization
The following Time Synchronization parameters are found in the Advanced tab of the STS
site configuration.
Time sync method <Extended Sync/Legacy Sync>
[Legacy Sync]:
This parameter defines the method to be used when sending time synchronization. In a
system with legacy RTUs, the sync method should be Legacy Sync.
Extended Sync RTU sends sync protocol frames containing time zone and
password, with nanosecond resolution. (1 millisecond accuracy
over synchronous media (radio) and over asynchronous RTU to
RTU media.)
Note: The RTU checks the password in extended sync frames and
authenticates sync messages before updating the clock. If it does
not match it will be rejected. See SW Diagnostics Device
TIMESYN level 10 for statistics of received/ignored sync frames.
Legacy Sync
This parameter determines the behavior of the RTU when it receives a legacy sync frame.
It has no meaning when receiving an extended MDLC sync. The valid values are:
Ignore legacy sync messages Do not update the clock when legacy sync messages
are received.
Dont ignore legacy sync messages Update the clock when legacy sync messages
are received. This is the default, so ACE3600 can
be synced from a MOSCAD or from another
ACE3600.
Time Zone
The following Time Zone parameters are found in the Advanced tab of the STS site
configuration.
Time zone learning mode <No time zone/User Configured>
This parameter determines how the time zone of the unit is set.
No time zone - RTU will have no time zone. The next parameter Time zone offset
in minutes will be ignored. If an extended time sync frame is
received, it will sync with the same time zone as the sending RTU. If
using a system control time such as GPS receiver or NTP server is
used, its time will be GMT time. The Daylight Savings database
table is ignored.
User Configured The user can set the local time zone in the Time zone offset in
minutes parameter. The daylight savings database table is read to
123
[0]:
The time zone offset from GMT, counting east. This parameter is relevant if the Time zone
learning mode parameter is set to User Configured.
[Disable]:
For PPP, 10/100 BT, USB Host connections. This parameter enables or disables
synchronization over IP. It must be enabled in both the sending and receiving unit in order
to synchronize. Note: Because the delay is unpredictable, enabling this parameter is not
recommended. Use NTP instead where possible.
Enable reply to time synchronization <Disable/Enable>
[Disable]:
For PPP, 10/100 BT and USB connections. Enables/disables reply to time synchronization
over IP.
124
125
126
NTP Setup
1. In MDLC over IP port (either RS232 PPP or 10/100 BaseT) select up to three NTP
servers. In some systems, where NTP servers are not available, specify another
RTU/FEP ACE3600. The IP address of NTP server can be either numeric such as
10.17.1.161 or host name such as www.ntp.comm.mot.com . The later format can be
used only if DNS servers were set or learned from the network. If you have several
MDLC over IP port, you can set-up several NTP servers, but make sure the above tree
structure is preserved.
2. Connect this server to a GPS or to another NTP server(s). Another option is not to
configure it with any GPS and NTP servers.
3. Set time zone. In the above first two cases you also need to set time zone in advanced
parameters, so it operates in local time. In the last case, where using a stand alone
ACE3600 as a server (no GPS and no NTP configured) there is no need to set a time
zone.
4. Make sure all servers are in sync. If you configure your primary sever as connected to
GPS, make sure it is able to receive satellites. Check GPS level 1 and NTP level 1 to
see it is synchronized, otherwise it will not be regarded as a valid server. If your
primary server is not configured for GPS and to any other NTP server, it is OK, but
make sure you have only one like that or sync it periodically to avoid clock drift from
other servers (for example by time sync it every few minutes).
The NTP advanced parameters explained in ACE3600 STS User Guide, Appendix A Site
configuration parameters. The most important parameters are shown below:
Max sync offset in msec <0-500>
[0]:
The maximum permitted offset of the RTU clock from its NTP server(s). If the offset
exceeds this amount, the NTP servers will be polled frequently to correct the offset,
possibly causing a heavy communication load. When set to 0, the offset is not checked. It is
recommended to leave this parameter set to 0.
Minimal poll interval in sec <1-64>
[4]:
The minimal interval in seconds between polling the NTP server(s). NTP works by polling
its servers. This is the minimal time in seconds that is polled. After a poll and sync, the
interval to the next poll is multiplied until reaching the Maximal poll interval in seconds.
(See the next parameter.)
Note: When contact with the server is lost, the minimal poll interval is used to resync as
fast as possible.
Maximal poll interval in seconds <1-1311072>
[1000]:
The maximal interval in seconds between polling the NTP server(s). See Minimal poll
interval in sec above. 1000 seconds is ~17 minutes.
Transmit BURST when poll <Yes/No>
[Yes]:
127
If this parameter is set to YES (default) when polling 8 messages are sent instead of one
every 2 seconds apart in order to sync as fast as possible. If NO only a single poll message
is sent.
Time sync lost before declare no sync in sec
[120]:
The number of seconds to wait before declaring no sync state after being in sync. When
no reply is received from the NTP server(s), or when getting invalid replies no sync is
declared, and the ClockValid in the Reserved Flags database system table is set to 0. 120 by
default means it takes 2 minutes to indicate that.
Notify error logger when losing sync <Yes/No>
[Yes]:
Whether notification should be sent to the error logger when declaring no sync. By
default this parameter is "YES", meaning a message is logged into error logger when
getting into "no sync" state after being in sync. If no sync again, no message is logged
until the user retrieves SW diagnostics device NTP level 10.
SITE: 2
LINK: LINE 2
DEVICE: NTP
LEVEL: 2
Fail
Prev
Next
Peer address
Flags poll
poll
delay
offset
disper.
maxrxtime
------------
----
-----
------
-------
-------
---------
10.5.1.160
*10.5.1.161
ETH1 30780 16
ETH1 30781 10
0000H
0000H
----
0301H 617
0341H 505
128
409
518
0.000
1.125
0.000
-0.729
0.000
0.071
0.000
3.396
The first column shows the status of the NTP server. 10.5.1.160 is unreachable because it
has no symbol, and 10.5.1.161 is reachable * marks it as a system peer. Both are polled
via ETH1. The stratum of the system peer is 10 meaning this is an ACE3600 which is not
connected to any NTP server or GPS receiver, otherwise it would have much smaller
stratum. The Prev and Next Poll designate in seconds when last time polled and when will
next poll occur. The delay is in milliseconds says 1.125 milliseconds delay to server. The
offset is also in milliseconds 0.729 milliseconds. The dispersion says how stable is the
clock, the less it is the better the clock. maxrxtime is for internal use.
Another method of testing NTP is using ntpq <ACE3600 IP address>. This utility is
provided in the STS installation and is a standard way of testing NTP. Refer to
http://www.eecis.udel.edu/~mills/ntp/html/ntpq.html for information on how to use this
utility. The most common commands are rv and pe to show clock status and NTP servers.
The default parameters values are set for the Oncore M12+T receiver, but may be changed,
as necessary.
129
[10]:
This field defines the interval between two time updates from the GPS receiver. . Note that
a drift of 30 ppm per day in ACE3600 RTU is 1.78 milliseconds per minute. Setting the
clock every 10 seconds will prevent this drift.
The GPS advanced parameters explained in ACE3600 STS User Guide, Appendix A Site
configuration parameters. The most important parameters are shown below:
Offset in milliseconds
Range: 0- 86400000
The field defines the time offset to add for
GPS time in the Universal Time Coordinate
(UTC). The range is 0-86400000 msec.
This parameter is for testing purpose and
should be left as 0. For adding local time
offset set it in time zone section of advanced
parameters.
Default: Disable
Range: Disable/Enable
If Enabled the GPS receiver will power up
with defaults from factory, taking it longer
to obtain time.
Default: Enable
Range: Disable/Enable
This parameter should be enabled for
M12+T timing receiver and disabled for
non- timing receivers.
If enabled, in order to perform precise
timing, the GPS receiver position is
determined and then the receiver is put into
Position-Hold mode where the receiver no
longer solves for position. With the position
known, time is the only remaining unknown.
When in this mode, the GPS receiver only
requires one satellite to accurately determine
time. If multiple satellites are tracked, then
the time solution is based on an average of
the satellite measurements.
130
RTS Always ON
Range: Yes/No.
This parameter should be left as NO since
RTS has no meaning in GPS.
Default: Active LOW
After setting the GPS parameters and downloading the configuration to the RTU, the unit
starts updating its time accordingly. You may use the Get Site Time & Date utility to
verify the RTU time.
Default: 120
The number of seconds to wait before
declaring no sync, when no reply is
received from the NTP server after a poll.
During this wait period, polling is increased.
If no sync is declared, the ClockValid flag
in the Reserved Flags database system table
is set to Nr (see the next parameter.) If GPS
is configured, no sync occurs when no
valid satellite status is received for this
period of time.
Default: Yes
Range: Yes/No
Whether notification should be sent to the
Error Logger when declaring no sync. By
default this parameter is "Yes", meaning a
message is logged into error logger when
getting into "no sync" state after being in
sync. If no sync occurs again, no message
is logged until the user retrieves SW
Diagnostics device NTP level 10.
132
ACE IP Gateway
The ACE IP Gateway for SCADA systems (CPU 4600) is an advanced unit based on
Freescales Power PC II MPC8270 microprocessor. It provides the SCADA software with
access to the ACE3600 and MOSCAD systems, based on the seven layers of the MDLC
protocol, in order to exchange data with the RTUs.
A typical example of the ACE IP Gateway (IPGW) is shown in the figure below; a SCADA
control center is connected via the ACE IP Gateway to RTUs on a radio link, to RTUs on
an RS485 link and to RTUs on an IP in the ACE3600 system.
The MDLC network communicates via the ACE IP Gateway with any SCADA computer
which supports TCP/IP (UNIX, Windows XP, etc.)
The SCADA control center, which includes workstations and a SCADA computer,
exchanges data with the ACE3600/MOSCAD system via the ACE IP Gateway, which
serves as a Gateway from the TCP/IP world to the MDLC world. There are many SCADA
packages which already have the Gateway Interface driver implemented, some as direct
access to the ACE IP Gateway, and some as OPC server.
133
ACE IP Gateway
The ACE IP Gateway uses the TCP/IP LAN Protocol for exchanging data application
messages with the SCADA software. The ACE IP Gateway API (Application
Programming Interface) allows SCADA driver developers to quickly and easily build the
ACE IP Gateway Interface (driver), which serves as a communication interface with the
MDLC world.
Data exchange between the SCADA (client) and the ACE IP Gateway (server) is carried
out using TCP/IP peer -to-peer communication over LAN. The ACE IP Gateway can
support multiple connections that are initiated from multiple SCADA computers.
The implementation of the ACE IP Gateway interface in the SCADA software allows the
SCADA to perform the following operations:
Poll an RTU in order to get data and COS (Change-of-State) events from the RTU
tables.
Send commands to the RTU and download parameters to its local process.
Receive spontaneous reports (by contention) from RTUs (both burst and event
transmission).
For a detailed description of the interface, please refer to the ACE IP Gateway API manual.
Conventional radio
Analog trunked radio
134
ACE IP Gateway
The communication system is used for transmitting alarms, status and telemetry, calculated
data diagnostics and error logging information from the RTUs to the central facility
computer and vice versa. It is also used for downloading, monitoring and debugging the
application program at the sites.
The system may be relatively simple, comprising several RTUs and a single control center,
or a more complicated hierarchical system, where several sub-control-centers communicate
with lower, parallel and higher hierarchies. The RTUs may also communicate with each
other and/or with any other hierarchy in the system.
The figure below depicts a system with more than one SCADA control center, an ACE IP
Gateway, and RTUs which are connected to a variety of media including RS232, RS485, IP
and radio link.
Note that the ACE3600 STS can be connected to the ACE IP Gateway or to any ACE3600
RTU over RS232 or over Ethernet.
135
ACE IP Gateway
The ACE3600/MOSCAD system uses the MDLC protocol, based on the seven layers of the
OSI model published by ISO, and adapted for SCADA communications. It provides
network support, multiple logical channels per physical port, allowing each RTU to
simultaneously run several communication sessions, such as data exchange, on-line
monitoring, diagnostics, etc.
The ACE3600 system is supplied with a Software Tools Suite (STS) package that runs on a
PC running Windows XP or Windows Vista. All RTU functions such as configuration,
database and process definition, downloading, monitoring, hardware and software
diagnostics, etc. are defined using the STS. The ACE3600 STS can communicate with the
Gateway via RS232 or IP.
The STS may be connected either locally to an RTU or via the MDLC port of the ACE IP
Gateway to any RTU in the system. All programming and monitoring functions can be
performed either locally or remotely. (The Gateway can serve as an MDLC router between
the ACE3600 STS and RTUs.)
Note: When the ACE3600 STS is connected locally to one of the RTUs in the system, it
can service any other RTU in the system via the MDLC communication network.
Multiple SCADA control centers can simultaneously perform multiple sessions with the
ACE IP Gateway in order to send commands and polling requests to the RTUs and to
receive data and contention reports from the ACE3600 RTUs. All this can be done via a
single physical Ethernet Gateway static LAN port. By default the Gateway port is ETH1,
but any Ethernet port may be used.
In a SCADA system, ACE3600 RTUs and ACE IP Gateways can use IP (Internet Protocol)
technology to interface to advanced radio infrastructure (e.g. digital ASTRO IV&D and
TETRA systems) and to standard private IP networks. MDLC and IP networks can be
integrated in the same system, as MDLC networking properties are preserved. MDLC
applications need not be modified as the lower layers of the protocol support IP. For
details on these various interfaces, see MDLC over IP Communication above.
SCADA Interface
Client-Server environment
The SCADA application for the ACE IP Gateway is based on a client-server approach.
The Gateway application acts as a server while the SCADA Interface acts as a client. In
such a relationship, the SCADA Interface must establish the connections with the Gateway
needed for communicating with the ACE3600 RTUs.
After the connections have been established, the SCADA Interface can send data,
commands, and polling requests to the field RTUs. It can also establish a special
connection that enables receipt of data transmissions initiated by the field RTUs (so called
burst/RTU event data, contention data or Change-Of-State [COS] messages).
Note: The ACE IP Gateway checks its connections to the SCADA from its end, to make
sure they are alive. At the same time, the SCADA must check from its end that its
connections to the ACE IP Gateway are alive.
136
ACE IP Gateway
Regular
Spontaneous
137
ACE IP Gateway
Connect
Poll
Receive
Troubleshooting
The ACE IP Gateway communication can be diagnosed using the STS Software
Diagnostics and Loggers tool. For detailed information, see the ACE3600 Software
Diagnostics and Error Messages manual.
MDLC Infrastructure
MDLC provides a frame-sequence service for the Health Check mechanism. Specifically, a
dedicated channel is allocated for this activity at both the RTU and the Gateway. All
Health Check messages are transmitted and received through this channel. Being a framesequence channel, the Health Check MDLC channel is both reliable and a low-resource
consumer at the same time.
MDLC provides a framework for the two entities (the Gateway and RTUs) to maintain this
mechanism but the actual protocol (data, timing, policy, etc.) is determined in the
RTU/Gateway firmware.
Mechanism
In the ACE IP Gateway, the Health Check mechanism relies on the MDLC infrastructure
denoted above. When activated, it takes the dedicated Health Check channel provided by
MDLC and uses the site table as a source for all sites to be managed. For each site, the
Health Check performs the following process:
At a predefined interval, the Gateway sends a ping frame to each site, one through each
of the sites links. It then expects to receive a response frame for each ping sent. A
ping arriving from a certain site through a certain link, will set the communication status
of that link to OK. A site that possesses at least one link in OK status is considered
138
ACE IP Gateway
reachable. This process constantly monitors the status of each sites links and provides the
ACE IP Gateway with an updated communication status of all sites in the field.
The Health Check protocol uses a minimal amount of system resources (length of data, and
time.)
On the RTU side, the Health Check mechanism relies on the MDLC infrastructure
described above. It operates in slave mode. When a ping frame is received by the RTU,
the RTU Health Check mechanism replies with an echo of that frame. The RTU transmits
a response back to the ACE IP Gateway over the same link. Unless it is pinged, the RTU
Health Check mechanism will not initiate any communication.
If the primary and secondary link IDs are identical (e.g. both RADIO 1), the Health
Check mechanism will assume the site possesses only one link and thus will not ping
the same site twice. The Secondary link validity value will be ignored.
If the primary and secondary link IDs are not identical (e.g. RADIO 1 and LINE 1), the
two paths to the site (one through each link ID) should not overlap in any part of the
route. If two different paths to the same RTU do overlap in part of the route, the
indications received from the Health Check mechanism regarding each link ID may not
be accurate.
139
ACE IP Gateway
IMPORTANT: If the primary and secondary link IDs are not identical (e.g. RADIO 1 and
LINE 1), the Primary link validity cannot be set to 000.00.00. 000.00.00 means that the
link will always be considered as valid, so:
1) This link will not be monitored by the Health Check mechanism.
2) The Secondary link will never be checked. (Therefore the STS will not permit
the user to set the primary link validity to be 000.00.00 and the secondary link
validity to another value.)
In this case, since the primary link is considered to be valid, the SCADA will always try to
transmit to the site over this link. If it transmits frequently, a bottleneck situation may
arise in the ACE IP Gateway due to lack of communication resources.
Therefore, the Primary Link validity should only be set to 000.00.00 in two cases:
1) An RTU that is defined in the project for future use but is not connected yet;
2) A non-node RTU with a single link access on which the Health Check will not
be performed. In this case, it is responsibility of the SCADA to identify and
handle communication failures to the site.
Note: Unlike the legacy IP Gateway which translated the 000.00.00 zero value to the
default value of five seconds, in the ACE IP Gateway, the Primary link validity of
000.00.00 is indeed 0 seconds, and effectively disables Health Check for the link.
For more information on configuring the links and the link validity intervals, see the
Managing Site Tables section in the ACE3600 STS User Guide.
Once the site table is set up, the ACE IP Gateway Health Check mechanism is activated in
ACE3600 STS site view in Advanced -> Frame Sequence Layer -> Health-check
(application) support parameter for the ACE IP Gateway and for all relevant RTUs. The
parameter is enabled by default.
For more details on the Health-check (application) support parameter, see Appendix A:
Site Configuration Parameters in the ACE3600 STS User Guide.
The STBLA software device diagnoses the active site table in the RTU.
The HELTHCH software device diagnoses the Health Check mechanism itself
For details on the software diagnostics, see the relevant sections in the ACE3600 STS
Software Diagnostics and Error Messages manual.
140
ACE IP Gateway
141
ACE IP Gateway
For more information on adding and configuring ACE IP Gateway Terminal Server ports in
the ACE3600 STS, see Customizing the Configuration of a Site in the Operation chapter of
the ACE3600 STS User Guide.
IP Address = xxx.xxx.xxx.xxx
SCADA Computer
ACE IP Gateway
IP Address = yyy.yyy.yyy.yyy
IP Address = zzz.zzz.zzz.zzz
PORT 2008
RTU #1
...
PORT 2008
RTU #N
RTU #1
...
RTU #N
ACE IP Gateway
Site ID 10044/2
Gateway
Designation
Startup Mode
Gateway
Designation
Startup Mode
Primary
Standalone
Primary
Standalone
142
ACE IP Gateway
Secondary
Redundant GW1
Secondary
Redundant GW2
After SCADA
driver changes the
Gateway
Redundancy Mode:
Primary
Redundant GW1
Secondary
Redundant GW2
Secondary
Redundant GW1
Primary
Redundant GW2
The primary Gateway communicates properly over MDLC communication and over the
SCADA channels. There is bi-directional transfer of both SCADA application messages
and ACE IP Gateway management messages.
The secondary Gateway transfers ACE IP Gateway management messages only. (It does
not send or receive any MDLC messages, since it is logically disconnected from the link.)
The secondary Gateway does not acknowledge any frame received by the MDLC
communication (except local connection).
The requests queued in the secondary Gateway will return errors once activated. (In
most cases this will be immediately. However, in some cases it could take as long as
the longest MDLC session timeout defined.)
The secondary Gateway disconnects from all the Terminal Server ports defined in the
site configuration.
When the primary Gateway becomes unavailable, the secondary (similarly configured)
Gateway takes over. To increase the availability of the LAN network, dual Ethernet
segments can be used, and each Gateway can be connected to a different segment.
When a Gateway is configured for redundancy, it checks each of the channels to the unit.
If all the channels to the Gateway are disconnected or unavailable, the Gateway
automatically switches to secondary mode.
143
ACE IP Gateway
communication to the RTU through the new primary ACE IP Gateway in order for the
RTU being able to send Bursts to it.
2. Both ACE IP Gateways are connected to the MOSCAD system over the same many-tomany media (i.e. RS485/Radio). In this configuration, when the secondary ACE IP
Gateway becomes primary, the ACE IP Gateways mode changes take effect immediately.
3. Both ACE IP Gateways are connected to the MOSCAD system over the same Terminal
Sessions. In this configuration, the old primary ACE IP Gateway must close all of the
Terminal Server connections, the terminal server must end its sessions with the old
primary ACE IP Gateway and then the new primary ACE IP Gateway must establish
connection with the Terminal server. In this configuration, several minutes may elapse
before the ACE IP Gateways mode changes take effect.
144
Core Dump
The main purpose of the Core Dump software component is to help the ACE developers to
identify the source and the reason of unexpected reboots. Core Dump is a diagnostic tool and
does not intervene in the application or software flow. In all of functionality modes described
below, the Core Dump software component becomes active only after the processor or the
VxWorks operating system notifies about an unrecoverable error (crash). When this happens,
the Core Dump saves some information before the RTU restarts. This information can be
uploaded later and analyzed off-line.
One example of a situation where the RTU will crash is when trying to divide by zero. (Some
applications cannot tolerate an undefined result of dividing by zero.) Another example is when
the software inadvertently tries to access illegal memory addresses. These scenarios are
common in user C applications.
When an RTU resets in the field, the indications of possible reasons for the failure are lost.
The Core Dump feature, when enabled, can save a frozen image of the full system memory
in use (including tasks, semaphore messages, variables, memory allocations, communication
buffers, etc.) before the reset. This provides the ACE developer with the full status of the
system at the time the memory image was taken and helps to pinpoint the cause of the failure.
The "frozen" image is actually a file which is analogous to "core dump" file of UNIX OS. The
"frozen" image file can be uploaded later for off-line analysis.
In order to save the image of the memory, the RTU freezes all tasks for approximately one
minute. During this time, the RTU will not monitor or control any devices. All LEDs except
for the ETH port will be frozen. If stopping all tasks for this period is not acceptable, (e.g. a
pump might continue operating unmonitored) the Core Dump can be set to Reduced
functionality (see below).
The Core Dump can also be configured to save partial information only (Reduced
functionality.) The partial information may contain descriptive messages, register values,
function callback traces of the failure from the system memory, the task that caused the failure,
etc. To save partial information, the RTU freezes all tasks for much less time, several
milliseconds, before it resets the RTU. After the restart, the ACE becomes active again.
In both Reduced and Full Functionality modes, the partial information is logged to the Error
Logger. In Reduced Functionality there is no core dump.
The Core Dump feature is configured in the ACE3600 STS site configuration using the SMA
Online advanced parameter in the Core Dump category. Reduced functionality is the default
setting. See Appendix A: Site Configuration Parameters in the ACE3600 STS User Guide.
IMPORTANT: Do not set SMA Online to Disable.
Uploading the Core Dump and its associated files can be done using the Core Dump Upload in
the STS. The Core Dump file, though saved in compressed format, may be very large (several
megabytes, depending on available physical RAM and its percentage of usage). An IP
connection or other fast media is recommended for the upload. For more information, see
Uploading the Core Dump Files in the Operation chapter of the ACE3600 STS User Guide.
145
Core Dump
146
MDLC Encryption
The MDLC Encryption add-on feature enables wireless communication over a distributed
system.
SCADA system components communicate using the MDLC protocol, based on the seven
layers of the OSI (Open Systems Interconnection) model published by ISO, and adapted for
SCADA communications. To secure the information being sent, the communication is
encrypted before being sent.
A time-based authentication system with clock synchronization incorporated into the user
application further enhances the security of the encrypted data.
For information on the MDLC Encryption feature, see the MDLC Encryption Feature User
Guide (Motorola publication number 6802971C35).
147
Protocol Analyzer
The Protocol Analyzer is a diagnostic tool which enables the user to monitor and analyze
MDLC communication over various channels in two different ways:
By means of an additional RTU defined as an adaptor that collects data for the Protocol
Analyzer. This adaptor monitors one port and transfers the received data through a
second port to the Protocol Analyzer program.
By monitoring the communication between two RTUs through RS-link, between a
computer and RTU through a computer Port, or between an RTU and an external
modem. This way of monitoring requires two 8 pin-to-25 pin female adaptors and two
serial ports on the STS computer.
a) Monitoring a Radio Link
The additional RTU should include a CPU module, radio and power supply. Using the STS
site configuration program, configure a CPU Port (e.g. port SI1) as RS232, Async, Protocol
Analyzer Port.
The CPU receives through a radio port all the frames (without address checking)
transmitted in the radio link, and transfers them through the Protocol Analyzer port to the
STS computer for evaluating, storing and displaying.
The radio port (e.g. PI2) should be defined according to the type of radio being used. A
third port (port SI2) can be defined as Computer Port to enable reconfiguration of the CPU
(back to normal mode of operation).
After configuring the CPU as a Protocol Analyzer, the following connections should be
performed as depicted below:
148
Protocol Analyzer
RTU
FIU
FIU
CENTRAL
RTU
PROTOCOL ANALYZER
PORT
PI1
PORT
SI1
PORT
SI2
RADIO
PORT
PI2
STS
CPU MODULE
RTU
RTU
RTU
2-WIRE MULTI-DROP
CENTRAL
PROTOCOL ANALYZER
PORT
PI1
PORT
SI1
PORT
SI2
PORT
STS
PI2
2-WIRE
MULTI-DROP
ADAPTER
CPU MODULE
149
Protocol Analyzer
ACE3600
RTU
TO
COMPUTER
OR
ACE3600 SITE
MONITORED
RS-232
8-pin
T-connector
TO PORT SI1
TO PORT SI2
25-PIN
FEMALE
ADAPTER
STS
PROTOCOL ANALYZER
Since the communication is full-duplex, two ports of the STS are used. You should use two
standard 8-pin T-connectors and two 25-pin female adaptors: one monitors the Tx Data and
the second the Rx Data of the communication refer to the following table.
Adaptor for RTU Tx Monitoring
8-pin
25-pin
female
Function
8-pin
25-pin
female
Function
STS Rx Data
STS Rx Data
GND
GND
7 (+12V)
DSR
7 (+12V)
DSR
150
Protocol Analyzer
Icons
The icons at the top of the Protocol Analyzer include Local Communication, Remote
Communication, Stop Monitoring, Pause Monitoring, Analyze, Print and Print Preview.
Menus
The menus in the menu bar include File, Monitor, and Help.
151
Protocol Analyzer
152
Protocol Analyzer
2. Enter the names (e.g. COM1) of the ports of the RTU to which the protocol
analyzer is connected. The order is irrelevant. For a remote link, only one port is
defined.
3. Enter the data speed of the link being monitored.
4. Enter the system address of the link being monitored.
5. Enter the name of the log file in which the monitored data should be collected (the
default is monc.dat.)
You can click on the browse icon to select the name of the desired .dat file. The
Open dialog box defaults to the log sub-directory of the STS directory where STS
stores log files by default.
The raw log file include the source site, the number of bytes that were collected
(size of the frame) and the frame contents.
6. Click on the desired format to be used (MDLC frames or Free Format).
MDLC Frames
Free Format
7.
Once the parameters are set, you are ready to start monitoring.
Opening a Log
1. To open and view an existing log file of raw data collected from a communication
link, select the Open Log command from the File menu.
Result: A dialog box is opened from which the user can select the desired .dat file.
The Open dialog box defaults to the log sub-directory of the STS directory where
STS stores log files by default.
153
Protocol Analyzer
The raw log file include the source site, the number of bytes that were collected
(size of the frame) and the frame contents.
2. Select the log file from the drop-down list and click OK to open it.
Note that the designation of the site (Site 0) simply means that the first monitored
data was transmitted from that site. When monitoring a multi-drop link (remote),
all logged monitored data will seem to originate from Site 0. When monitoring an
RS232 link, the data will either be marked Site 0 (first to transmit) or Site 1
(second to transmit).
154
Protocol Analyzer
155
Protocol Analyzer
2. Under Analyzer options, specify which MDLC layers are to be considered during
the data analyze. Click on whichever layers of the MDLC protocol you want to be
considered during the data analyze. Click the Bytes layer when you want to see the
data in a stream of hexadecimal bytes.
3. Under Source Address Ranges, specify the address range of the transmitting site.
Enter the starting and ending (decimal) addresses of sites (Site ID) whose data is to
be analyzed when transmitting data over the link. (RTU address= Site ID + System
address)
Under Destination Address Ranges, specify the address range of the receiving site.
Enter the starting and ending (decimal) addresses of sites (Site ID) whose data is to
be analyzed when receiving data over the link. (RTU address= Site ID + System
address)
4. For Free Format data, under Non-MDLC Frame Delimiters specify frame
delimiters for dividing the data stream as decimal values of hexadecimal Start/End
frame delimiters. The default Start and End values are 1, which cause the data to
be displayed in a stream of up to 200 hexadecimal bytes with no delimiters. If
other Start/End values are entered, the displayed data stream will be divided based
on the specified delimiters.
156
Protocol Analyzer
5. Once the preferences have been defined, click OK to begin the data analysis.
Printing a File
To send the current file to be printed, select the Print command from the File menu. This
command functions like the standard Windows Print command.
157
The measured process value is converted by the transducer into voltage or current, which in
turn is converted by the A-to-D converter into a scaled analog input - a real (32-bit floating
point) value designated by the symbol pidIN which represents the current value of the
measured process.
The PID block is driven by the error signal (E) calculated as the difference between the
setpoint - pidSP (the desired value) and pidIN (the actual value).
The PID block transfer function is defined by its parameters. Its output, pidOUT, is a real
(32-bit floating point) value, driving the D-to-A converter.
The output of the D-to-A converter, voltage or current, is used as the controlling drive for
the process.
The purpose of the loop is to minimize the error E(t) by driving the process to follow the
setpoint value.
If E(t) = SP(t) - IN(t), then the transfer function of the PID block is defined as follows:
where:
158
dE ( t )
dt
IN(t) the PID input that represents the measured process value in "Input
Engineering Units" [IEU].
SP(t) -
E(t) -
OUT(t) - the output of the PID loop in "Output Engineering Units" [OEU].
K-
Ki -
Kd -
PID Function
The PID function performs the following three calculations:
The proportional calculation, whose contribution to the output signal is directly
proportional to the error signal.
The integration, whose contribution to the output signal is proportional to the integral of
the error between 0 to t plus I0, which serves as the initial value of the integral (for t=0).
The integral drives the process of the setpoint value with a zero position error.
The derivation, whose contribution to the output signal is proportional to the rate of
change of the error signal.
PID Table
To access the PID table, open an application using the Application Manager in the STS, the
Application Manager command in the STS GUI or the Application Programmer utility in
STS Start Menu program list. In the Database tab, click on User Tables to open the list of
database user tables, as shown below.
159
If no PID Table appears in the list of user table names, it must be created. Right-click on
the User Tables and select Append Table -> PID Table from the context menu.
If PID Table appears in the list of user table names, double-click its name in the table
name list.
The following is displayed:
The PID table includes the following parameters. For more details on each parameter, see
the example project:
pidIN - the scaled analog input (32-bit floating point value) that represents the
controlled process.
The value in this column is updated when the SCAN function using this column name
is called.
160
pidSP - this variable represents the setpoint, the desired state of the controlled process.
This is a real parameter variable that has an initial value for each row (each loop).
You may modify the value of this variable in the rungs when a change in the controlled
process is needed.
pidK - this real parameter variable represents the gain of the loop. Its initial value
usually remains the same. The value of this variable may be modified in the rungs.
pidKd - derivative factor in seconds that controls the output correction rate at which the
output responds to the change of error. A value of zero will disable the derivative
action. The value of this variable may be modified in the rungs. Default: 0.0
pidKi - integration factor in "repetitions per second. A value of zero will disable the
derivative action. The value of this variable may be modified in the rungs. Default: 0.0
pidDb - this variable defines the PID output dead band. It prevents frequent changes of
the pidOUT variable when the absolute value of the difference between the new
calculated value and the current value is smaller than the pidDb value. When pidDb=
pidOUT, the pidOUT variable is always updated by the PID. Default: 0.0
pidOUT - the scaled analog output (32-bit floating point value) that drives the process.
Note that the PID table, like all other User tables in the database, can be edited, deleted,
searched, or converted to a printable file. Rows can be added, as can a table description.
161
Glossary
CV - Controlled Value: The measured or calculated process input
SP - Process SetPoint value
Err - Process error = SP - CV
AO - Process Analog Output: Sets the position of the controlled element
Validity Check - The process variables are to be within a predefined valid range.
Note: Setting the PID function parameters requires some knowledge about tuning PID
loops. The current version of PID function and the application example described below,
does not include 'self tuning' feature. The user has to set them manually, write additional
application or use external PC based software for this purpose.
2. The integral part of the PID contributes to its output the result of
[(PidK*PidKi) * Integral of (Err)], where the summation is performed every time the PID
calculation is performed. That means that AO increases as long as Err is positive, and AO
decreases as long as Err is negative. The summation result is stored in the PidInt variable,
where it can be set by the application too.
The PID function does not put a limit to the integral part. In certain cases, this may cause
the AO to reach its low or high limits. The application, as explained later, has to deal with
such situations.
3. The derivative part of the PID contributes to its output the result of
(PidK*PidKd) * (Err rate of change). That means that AO increases as long as Err rate of
change is positive, and AO decreases as long as Err rate of change is negative. If Err is
constant the derivative portion of the PID function equals to zero.
In the described example the derivative factor was set to zero, since its action is not
required for flow control.
Operation Mode
A PID loop can be either in Auto mode or in Manual mode. In Auto mode, the operator
can set the required flow and the PID function sets the AO according to process conditions.
In Manual mode, the operator can set the position of the regulating valve directly, and the
PID function results are ignored.
The ACE3600 application handles the transition from one operation mode to the other.
Validity Check
The controlled value of a loop is usually an analog input. The application in the following
example also supports the validity check of the CV, in order to prevent loop malfunction.
The PID setpoint is also checked to be within predefined limits. If it exceeds these limits, it
is operates according to the minimum or maximum setpoint range accordingly.
Moreover, the resulting AO of the PID function is also checked for validity before updating
the physical analog output.
The PID application, described in this section, uses the built in PID table, with additional
User tables and process, to control the CV (e.g. pipe flow) by setting the position of the AO
(e.g. regulating valve). The inputs of the function are the required flow (SP) and the
measured flow (CV).
Database Tables
The database tables are shown below. Each variable used in the tables is described.
163
CV_Set
(int)
AO_Set
(int)
COS name:
Last index (Ind): 0
Last index name: LstPid
ModSet
(iprm)
0
PID Table
Table name: PID Table
Table symbol:
Ind
pidIN
(sAI)
Ind
pidIN
Ind
0
PidOUT
COS name:
Last index (Ind): 0
Last index name: I_PID
pidSP
(rprm)
pidK
(rprm)
pidKd
(rprm)
pidKi
(rprm)
pidInt
(rprm)
PidDb
(rprm)
0.0
3.0-4
0.0
10.0
0.0
0.0
EGU
Zero
EGU High
100%=Full Scale
0%
0.0
1.0
EGU Zero
EGU High
100%=Full Scale
0%
0.0
1.0
PidOUT
(sAO)
pidIN - PID controlled value input. - Represents the controlled value (CV). This value is
not linked directly to the analog input and is updated by application. The scaling of the
input can be defined in this column, by setting the EGU Zero and EGU High accordingly.
164
Ind
COS name:
Last index (Ind): 0
Last index name:
Pid_AI
(sAI)
Pid_AO
(sAO)
Pid_AI
EGU Zero
EGU High
100%=Full Scale
20%=Live Zero
0.0
100.0
EGU Zero
EGU High
100%=Full Scale
20%=Live Zero
0.0
100.0
Ind
0
Ind
0
Pid_AO
EGU High used to define the scaling of the PID controlled value input pidIN
Ind
PID_P
(rprm)
PID_I
(rprm)
3.0-4
10.0
COS name:
Last index (Ind): 0
Last index name:
COS name:
Last index (Ind): 0
Last index name:
Ind
AlrDB
(rprm)
AlrTim
Mn:Sc
CV_Min
(rprm)
CV_Max
(rprm)
AO_Min
(rprm)
AO_Max
(rprm)
5.0
05:00
0.0
15000.0
0.0
100.0
166
Ind
PidDif
(real)
DifTmp
(real)
COS name:
Last index (Ind): 0
Last index name:
RTemp
(real)
O_Max
(bit)
O_Min
(bit)
PidAlr
(bit)
PidDif - Difference (Err) between setpoint (SP) and process controlled value(CV)
DifTmp Process error in CV engineering units
RTemp - Process error in percents of CV full scale
O_Max - Temporary bit. Indicates that output has reached its maximum position
(AO_Max)
O_Min - Temporary bit. Indicates that output has reached its minimum position (AO_Min)
PidAlr - Pid loop alarm flag. This alarm indicates that the PID process value did not reach
its setpoint (including the AlrDB deadband) within the predefined time (AlrTim)
Name
Value
TPID
01:00
COS name:
Last index (Ind): 0
(Sc:Ms)
TPID - PID calculation time interval (multiplied by 10 ms). The timer preset value is set by
PtPID.
Name
BTemp
COS name:
Last index (Ind): 0
Value
Name
Value
PtPID
100
COS name:
Last index (Ind): 0
PtPID - A parameter to set PID calculation time interval (10msec resolution). The
minimum setting for running 8 PID loops is 100 (1 second).
Constants
The application uses the following constants:
Integer Constants - Manual = 0, Auto = 1
Real Constants - R0 = 0.0, R100 = 100,0
Description
Scan PID AI
Reset Index p
Local Setpoints
Local Setpoints
Manual mode limits
Manual Mode
Jmp P50 if no TPID
Auto Mode
Check Input range
Increment Index p
Check Index p
Run PID Calc
Jmp P200 if no TPID
Reset Index p
Check Output range
Calc PID loop error
Set PI factors
168
P114
P115
P130
P140
P200
P210
P05
Rung P10: The number of PID loops which are controlled by the application is set by the
number of rows in the PID Table. The same application with an index 'p' handles all loops.
This rung resets 'p' index to run the first PID loop.
p
( RST )
P10
Rung PL12: In Auto mode, the Pid_AO is always copied to AO_Set. This enables smooth
transition to Manual mode without a step change in the loop SP.
PL12
AO_Set,p
(MOVE)
Pid_AO,p
ModSet,p
=
Auto
Rung P18: In Manual mode, the AO_Set value is checked to be within a predefined range
(AO_Min and AO_Max). If it exceeds these limits, the output is set to the relevant limit.
P18
ModSet,p AO_Set,p
=
>
Manual
AO_Max
Pid_AO,p
(MOVE)
AO_Max,p
AO_Set,p
<
AO_Min
Pid_AO,p
(MOVE)
AO_Min,p
Rung P20: In Manual mode, the Pid_AI is checked to be within a predefined range
(CV_Min and CV_Max) and copied to CV_Set. This enables smooth transition to Auto
mode without a step change in the loop PidSp.
169
In addition, the AO_Set value is checked to be within a predefined range (AO_Min and
AO_Max) and is copied to Pid_AO, and PidInt. Updating the latter variable is also
important to keep the AO in the last position when loop mode is changed to Auto, while
there is no change in the setpoint.
P20
ModSet,p Pid_AI,p
>
=
Manual CV_Min,p
Pid_AI,p
>
CV_Max,p
Pid_AI,p
=
CV_Min,p
Pid_AI,p
=
CV_Max,p
AO_Set,p AO_Set,p
>
<
AO_Min
AO_Max
AO_Set,p AO_Set,p
=
=
AO_Min
AO_Max
pidSP,p
(MOVE)
Pid_AI,p
CV_Set,p
(MOVE)
pidSP,p
Pid_AO,p
(MOVE)
AO_Set,p
pidInt,p
(MOVE)
Pid_AO,p
Rung P21: Skips the next two rungs when PID loop is not calculated.
P21
TPID
/
P50
( JMP )
Rung P25: In Auto mode, the CV_Set (set by the operator) is checked to be within a
predefined range (CV_Min and CV_Max) and copied to PidSp. In addition the AO_Set
value is updated by the Pid_AO.
P25
ModSet,p CV_Set,p
>
=
Auto CV_Min,p
CV_Set,p
<
CV_Max,p
CV_Set,p
=
CV_Min,p
CV_Set,p
=
CV_Max,p
170
pidSP,p
(MOVE)
CV_Set,p
AO_Set,p
(MOVE)
Pid_AO,p
Rung P30: In Auto mode, the Pid_AI is checked to be within a predefined range (CV_Min
and CV_Max) and copied to PidIn accordingly.
P30
ModSet,p Pid_AI,p
>
=
Auto CV_Min,p
Pid_AI,p
<
CV_Max,p
Pid_AI,p
=
CV_Min,p
Pid_AI,p
=
CV_Max,p
pidIN,p
(MOVE)
Pid_AI,p
Pid_AI,p
>
CV_Max,p
pidIN,p
(MOVE)
CV_Max,p
Pid_AI,p
<
CV_Min,p
pidIN,p
(MOVE)
CV_Min,p
Rung P50: Counts up (increments) the index counter (to execute the next loop).
p
( CTU )
P50
P60
PL10
(JMP)
p
=
I_PID
Rung P90: Runs the PID calculation on all loops every TPID interval.
TPID
P.I.D.
( CALL )
P90
Rung M91: Skips the next rungs, which check the PID function results, if PID function was
not performed.
M91
TPID
/
P200
( JMP )
171
P100
Rung P110: Checks the PidOut (PID function output) to be within a predefined range
(AO_Min and AO_Max), and copies it to Pid_AO accordingly.
P110
ModSet,p pidOUT,p
<
=
AO_Min,p
Auto
Pid_AO,p
(MOVE)
AO_Min,p
pidOUT,p
>
AO_Max,p
Pid_AO,p
(MOVE)
AO_Max,p
pidOUT,p pidOUT,p
>
<
AO_Min,p AO_Max,p
Pid_AO,p
(MOVE)
pidOUT,p
pidOUT,p pidOUT,p
=
=
AO_Min,p AO_Max,p
Rung P112: PID loop performance is checked. If the output fails to be within a predefined
range (PidSp +/- AlrDB) for longer than AlrTim, an alarm flag (PidAlr) is set.
P112
PidDif,p
- pidSP,p
Pid_AI,p
ModSet,p
=
Auto
DifTmp,p
(MOVE)
PidDif,p
DifTmp,p
<
R0
DifTmp,p
- R0
DifTmp,p
RTemp,p
(CALC)
RTemp,p
>
AlrDB,p
AlrTim,p
AlrTim,p
(DON)
PidAlr,p
(
)
172
Rung P113: In order to prevent large fluctuations in output when Rtemp (process error in
percents) is greater than AlrDb (user defined parameter), the application divides the PidK
by a constant 100. In order to keep the integral factor unchanged, it is multiplied by the
same constant. Thus, the Integral action is dominant when process error is large, and the
Proportional action is more dominant when process error is small.
P113
ModSet,p RTemp,p
>
=
AlrDB,p
Auto
pidK,p
/ PID_P,p
R100
RTemp,p
=
AlrDB,p
pidKi,p
x PID_I,p
R100
pidK,p
(MOVE)
PID_P,p
RTemp,p
<
AlrDB,p
pidKi,p
(MOVE)
PID_I,p
Note: The constant is used for the example only. For a practical PID loop, the proper
constant (or other type of handling these factors) must be implemented.
Rung P114: In Auto mode, when PidOut exceeds AO_Max, it is kept at that level. The first
time the process error becomes negative, the AO_Max is copied to PidInt. This operation
eliminates the effect of positive accumulated value of the Integral portion when AO is in its
maximum position.
P114
ModSet,p pidOUT,p
>
=
AO_Max,p
Auto
O_Max,p
O_Max,p
( L )
PidDif,p
<
R0
pidInt,p
(MOVE)
AO_Max,p
O_Max,p
(U )
173
Rung P115: In Auto mode, when PidOut exceeds AO_Min, it is kept at that level. The first
time the process error becomes positive, the AO_Min is copied to PidInt. This operation
eliminates the effect of negative accumulated value of Integral portion when AO is in its
minimum position.
P115
ModSet,p pidOUT,p
<
=
Auto AO_Min,p
O_Min,p
O_Min,p
( L )
PidDif,p
>
R0
pidInt,p
(MOVE)
AO_Min,p
O_Min,p
(U )
Rung P130: Counts up (increments) the index counter (to execute the next loop).
p
( CTU )
P130
P110
( JUMP )
p
<
I_PID
p
=
I_PID
Rung P200: Writes the resulting analog output to Pid_AO by Scan operation.
Pid_AO
( SCAN )
P200
TPID
P210
TPID
/
TPID
(DON)
174
Enhanced PID
The ACE3600 Enhanced PID Application enables the ACE3600 to control up to 32
independent PID loops (independent processes), each with five PID modes: one manual
and four types of auto modes. The PID calculation algorithm depends on the chosen mode.
The ACE3600 Enhanced PID Application includes a powerful tool for graphically
monitoring the control process, which also enables interactive PID coefficient tuning.
If a legacy PID loop application exists in the RTU, an Enhanced PID application can also
be defined for the RTU.
The Enhanced PID Application is installed as a separate add-on option (FVN5680A) to the
STS.
For more information, see the ACE3600 Enhanced PID Application User Guide, provided
with the STS installation in [C]:\STS<version>\STSManuals.
175
Irrigation
The ACE3600 STS can be used to build, configure and maintain sophisticated distributed
SCADA-based (Supervisory Control and Data Acquisition) irrigation systems. The
elements and handling of irrigation systems differ slightly from other SCADA systems.
An irrigation system consists of an IRRInet Control Center (ICC), field units (RTUs) and
portable device for on-site programming of field units.
For detailed information on planning and setting up an irrigation system, see the IRRInetM System Planner.
IRRInet-ACE
The IRRInet-ACE unit is an ACE3600 RTU running the Irrigation (Master) application.
Its hardware and system software is identical to that of the ACE3600 RTU.
The IRRInet-ACE supports two modes of operations:
RTU Performing all irrigation functions, reporting to the IRRInet Control Center
(ICC).
Stand Alone Performing all irrigation functions as a stand-alone unit when the system
is installed without an ICC.
With DIOS (Distributed I/O System) connectivity, the IRRInet-ACE can activate PiccoloXR units with its PIU (Piccolo Interface Unit) functionality.
The IRRInet-ACE RTU can be programmed on site, using an IRRinet Terminal for Pocket
PC.
The IRRInet-ACE may be installed in a totally new irrigation system, or in a legacy system
in addition to/instead of a legacy IRRInet-XL or IRRInet-XM unit.
176
Irrigation
IRRInet-M Master/Slave
There are two types of IRRInet-M:
RTU Performing all irrigation functions, reporting to the ICC via MDLC network.
(loaded with the IRRIV Master application)
Stand Alone Performing all irrigation functions as a stand-alone unit when the system
is installed without an ICC. (loaded with the IRRIV Master application)
Remote I/O Serving as a distributed I/O for another master unit that performs all
irrigation functions (when loaded with the IRRIV Slave software).
This is applicable when multi-site control synchronization is needed.
Designing the system (areas, sites, communication links) in a graphical desktop, with a
system-wide (multiple sites/areas) approach
Configuring the RTU sites (unit ID, ports, I/Os, advanced parameters)
Downloading/uploading files
For detailed information on using the STS to configure and deploy units, see the ACE3600
STS User Guide.
177
Irrigation
IRRInet-M
Slaves/Routers
PIU
RSlink1
RTU 1
RSlink2
STS
PC
RTU 101
Radio
(Intrac)
Radio1
RTU 2
RSlink2
Scorpio
PIU
RSlink1
RSlink19
RTU 100
Legacy Units
RTU 102
Radio
(Intrac)
Scorpio
Radio1
PIU
RSlink1
FIU
RTU 3
Radio1
RSlink2
.
.
RTU 103
Radio
(Intrac)
PIU
RSlink1
RTU 99
RSlink2
Scorpio
RTU 199
Radio
(Intrac)
Scorpio
Irrigation systems such as the one depicted above should not use the generic network
configuration table produced automatically by the STS. Instead, a customized network
table should be created and maintained, as follows:
1. After defining two connected sites (RTU 100 and RTU 1) with their links (RSlink19
and Radio1 for RTU 100, and Radio1, RSlink1, RSlink2 for RTU 1), save the generic
network configuration table produced by the STS as a private network table. (See the
Managing the Network and Editing a Network Table sections in the Operation chapter
178
Irrigation
of the ACE3600 STS User Guide.) Initially, the network table should have two entries
in it.
2. Delete the second entry (for RTU 1), leaving one entry with a Site ID and two (or more)
Link IDs.
3. Continue defining the rest of the RTUs in the system, using the following convention:
Only links from the RTU to PIU units should be named RSlink1.
Only links from the RTU to IRRInet-M Router (for connection to Scorpio, Impact, and
IRRIcom legacy units) should be named RSlink2.
4. Edit the customized network table to show only those communication nodes which are
not connected to PIU and legacy units.
5. To simplify the viewing the system in the GUIs Diagram view, it is recommended to
hide the RSlink1 and RSlink2 links in the display. To do so, click on the Links button
in the System view.
File
Extension
Ladder
Application
.b, .s
PLC 1, 2, 3
.fls
PLC to Master
1, 2, 3
.fls
C Application
.fls
IP
Configuration
.ipp
179
Irrigation
File Type
File
Extension
C Application
Parameters
*.*
IP Conversion
Table
.ipc
Important: Because the irrigation system works with ICC V14, all legacy irrigation RTUs
must be upgraded to V570 of the project files.
180
This appendix provides the information required for connecting an RTU RS232 port to various
units, as detailed below:
ACE3600 RTU-to- ACE3600 RTU connection using MDLC protocol through RS485 ports
(RS-Link)
ACE3600 RTU-to- MOSCAD RTU connection using MDLC protocol through RS485
ports (RS-Link)
ACE3600 RTU main CPU to expansion module direct connection (for systems with I/O
expansion only)
ACE3600 RTU main CPU to expansion LAN switch connection or connection of the first
LAN switch to the second, if such exists (for systems with I/O expansion only)
ACE3600 RTU expansion LAN switch to expansion module connection (for systems with
I/O expansion only)
A-1
The signals that appear on the female 25-pin or 9-pin D-type connector are according to the
RS232 standard see the following table. In this case, the RTU serves as DCE (Data
Communication Equipment).
RS232 Function
8-pin Connector
(on RTU)
25-pin
Female
9-pin Female
Direction
TX-DATA
from DTE
RX-DATA
to DTE
RTS
from DTE
CTS
to DTE
DSR
to DTE
GND
DTR
20
from DTE
to DTE
To extend the cable, you may use any extension cable with male and female D-type connectors
(connected pin-to-pin, not crossed).
Note: When a User port is defined as Computer/Terminal with DTR support:
1) The RTU will not transmit unless it receives DTR=ON from the computer/terminal.
2) The RTU will not receive unless it receives RTS=ON from the computer/terminal.
Connection to a Modem
To connect one of the RTU RS232 ports to an RS232 modem, use one of the adaptors
provided in kit FLN6458B (option V213AE):
8-pin Connector
(on RTU)
A-2
25-pin Male
9-pin Male
Direction
RS232 Function
8-pin Connector
25-pin Male
9-pin Male
Direction
(on RTU)
TX-DATA
from RTU
RX-DATA
to RTU
RTS
from RTU
CTS
to RTU
GND
DTR
20
from RTU
to RTU
To extend the cable, you may use any extension cable with male and female D-type connectors
(connected pin-to-pin, not crossed).
Before transmitting, the RTU sends RTS=ON to the modem, and waits for CTS=ON from the
modem as a condition for transmitting.
The RTU will receive data from the modem only when DCD=ON.
When using a modem in auto-answer mode (connected to a Computer port) for remote service,
the RTU does not support RTS/CTS protocol since the port is designated to operate with a
local computer as well as with a modem.
For modems which support RS232-E, use either the RS232-E adaptor (#0189968V33) as in
Connection to IDEN Radio below, or the RS232-E+ adaptor (#0189968V34), as in Connection
to TETRA Radio below.
not defined by the RS232 standard, every printer manufacturer has defined the connectors for
his own convenience. Therefore, select the adaptor according to the functions of the various
pins.
If the FLN6458B adaptor (with the male 9-pin D-type connector) is used, refer to the following
table.
RS232 Function
9-pin Male
Used as
Direction
TX-DATA
Serial Data
to Printer
CTS
Printer Ready
from Printer
GND
GND
If the FLN6457B adaptor (with the female 9-pin, D-type connector) is used, refer to the
following table.
RS232 Function
9-pin Female
Used as
Direction
RX-DATA
Printer Rx-Data
to Printer
DTR
Printer Ready
from Printer
GND
GND
Connection to a Radio
For detailed instructions on connecting a radio to the ACE3600 RTU, see the Radio Types and
Installation Kits chapter in the ACE3600 RTU Owners Manual.
A-4
RS232 Function
8-pin Connector
(on RTU)
9-pin Male
Direction
TX-DATA
from RTU
RX-DATA
to RTU
CTS
to RTU
GND
CD (Rec line)
to RTU
RTS
Not used
from RTU
from RTU
DTR
8-pin Connector
(on RTU)
9-pin Male
Direction
TX-DATA
from RTU
RX-DATA
to RTU
CTS
to RTU
GND
CD (Rec line)
to RTU
RTS
from RTU
Not used
DTR
A-5
from RTU
USB Type A
(on RTU)
26-pin Female
(on Radio)
Direction
+5 VDC/
VBUS+
from RTU
Data -
to/from RTU
Data +
to/from RTU
GND
25
from radio
power cable
Ignition
IMPORTANT
Do not connect between RTUs without the adaptor cables. A direct connection will
cause a short circuit between the pins that have the same function.
8-pin Connector
(on sending RTU)
8-pin Connector
(on receiving RTU)
Direction
TX-DATA
from RTU
RX-DATA
to RTU
CTS
3 + 6
from RTU
Signal GND
CD (Rec line)
3 + 6
to RTU
RTS
6 + 3
from RTU
A-6
RS232 Function
8-pin Connector
(on sending RTU)
8-pin Connector
(on receiving RTU)
Direction
TX_CLK
from RTU
RX_CLK
to RTU
8-pin Connector *
(on ACE3600)
B (RX/TX-)
A (RX/TX+)
IMPORTANT
Do not connect between RTUs without the adaptor cables. A direct connection will
cause a short circuit between the pins that have the same function.
RS485 Function
8-pin Connector
(on ACE3600)
4-pin Connector
(on MOSCAD)
B (RX/TX-)
A (RX/TX+)
A-7
To establish a link between an ACE3600 unit and the Ethernet port of a PC, without using a
hub, the RTU port should be defined as an IP port (10/100 BT, Static, Ethernet LAN) with an
IP address. The ports should be connected using an Ethernet crossover cable.
IP Function
8-pin Connector
(Plug 1)
8-pin Connector
(Plug 2)
TX-DATA +
TX-DATA -
RX-DATA +
N/A
N/A
RX-DATA -
N/A
N/A
The ACE3600 RTU main CPU can be connected to an expansion module via one or two
expansion LAN switches. The CPUs ETH1 port should be configured as I/O Expansion
Comm.
For the connections below, use a standard standard Category 5E shielded (FTP) LAN cable (up
to 50m.)
ACE3600 RTU main CPU to expansion LAN switch connection or connection of the first
LAN switch to the second, if such exists (for systems with I/O expansion only)
ACE3600 RTU expansion LAN switch to expansion module connection (for systems with
I/O expansion only)
IP Function
8-pin Connector
(Plug 1)
8-pin Connector
(Plug 2)
TX-DATA +
TX-DATA -
RX-DATA +
N/A
N/A
RX-DATA -
N/A
N/A
A-9
Modem Settings
AT&F0
ATB0
ATN0
AT&D0
AT&K0
ATS0=1
ATS37=9
AT&W0
AT&Y0
B-1
Command Summary
(* indicates a change from the default)
*
*
B0
E1
L1
M1
N0
Q0
T
V1
W0
X4
Y0
&C1
&D0
&G0
&J0
&K0
&Q#
&R1
&S0
&T5
&X0
&Y0
B-2
S-Registers
(* indicates a change from default)
*
*
S00=001
S037=009
B-3
Modem Settings
AT&F0
ATB0
ATN0
ATT
AT&C1
AT&D0
AT&K0
ATS0=1
ATS37=9
AT&W0
AT&Y0
B-4
B-5
Motorola OnlineSURFR
External
MODEMSURFR 28.8 EXT
3696
Modem Settings
AT&F0
ATB0
AT&D0
AT&R1
AT%C0
AT%G0
AT\N0
AT\Q0
AT\V1
AT-J0
ATH0
ATS0=1
ATS37=9
AT&W0
AT&Y0
B-6
Command Summary
(* indicates a change from the default)
*
*
B0
E1
L2
M1
Q0
V1
W0
X4
*
*
*
*
*
*
*
&B1
&C1
&D0
&G0
&L0
&P0
&Q0
&R1
&S0
&X0
&Y0
%A013
%C0
%G0
\A3
\C0
\G0
\J0
\K5
\N0
\Q0
\T000
\V1
\X0
-J0
H0
O032
B-7
S-Registers
(* indicates a change from default)
*
*
S00=001
S037=009
B-8
Motorola OnlineSURFR
External
MODEMSURFR 33.6 EXT
0597
Modem Settings
AT&F0
ATB0
AT&D0
AT&R1
AT%C0
AT%G0
AT\N0
AT\Q0
AT\V1
AT-J0
ATH0
ATS0=1
ATS37=9
AT&W0
AT&Y0
B-9
Motorola OnlineSURFR
External
MODEMSURFR 56K EXT
0598
90709647 (Sayreville staging)
Modem Settings
AT&F0 Restore factory configuration 0
AT+MS=9,0,9600,9600 Modulation mode (9=V.32, 9600 or 4800), 0=forced, min speed=9600, max
speed=9600
AT&D0 Modem ignores DTR
ATE0 Turn off command echo
AT&R1 CTS is always active
AT&K0 Disable computer/modem flow control
AT\N1 Normal speed buffered mode (no error correction)
AT%C0 Disable data compression
ATS0=1 Rings to autoanswer = 1
AT\V1 Connect messages displayed in single line format
ATW2 Report modem-to-modem speed in error correction mode
AT&W0 Store active profile in NVRAM profile 0
AT&Y0 Recall stored profile 0 upon power up
B-10
UDS V.3225
Modem
Type
Model
Version
UDS V.3225
External
V.3225 LCD MINI SA
Modem Settings
Instructions to load Factory Option Set #2 (Asynchronous Dial-up without MNP)
(Settings are made from front panel of modem.)
B-11
Press NO
Press NO
Press NO
Press NO
Press YES
Press NO
Press NO
Press NO
Press NO
Press NO
Press NO
Press YES
Press YES
Press YES
Press NO
Press YES
Press YES
Press YES
Press TALK/DATA
MODEM PARAMETERS
DCE RATE = DTE RATE
NORMAL ORIGINATE
FAST TRAIN DISABLED
AUTO RETRAIN ENABLED
TRANSMIT CLOCK INTERNAL
DIAL LINE
JACK TYPE RJ11 (PERMISSIVE)
LINE CURRENT DISCONNECT LONG ENABLED
LONG SPACE DISCONNECT ENABLED
V.22 GUARD TONE DISABLED
MNP PARAMETERS
MNP PROTOCOL DISABLED *
DTE SPEED = DCE SPEED *
FLOW CONTROL DISABLED *
XON/XOFF PASS THROUGH DISABLED
DATA COM
PRESSION ENABLED *
MNP ACTIVITY TIMER OFF
MNP BREAK CONTROL 0 *
DTE PARAMETERS
ASYNC DATA
DTE RATE = 9600
8 BIT
NO PARITY
AT COMMAND SET ENABLED
IGNORES DTR
DSR FORCED HIGH
DCD FORCED HIGH
CTS FORCED HIGH
DTE FALLBACK DISABLED
OPTIONS RETAINED AT DISCONNECT
TEST PARAMETERS
BILATERAL ANALOG LOOP DISABLED
BILATERAL DIGITAL LOOP DISABLED
DTE LOCAL TEST DISABLED
DTE REMOTE TEST DISABLED
REMOTE COMMANDED TEST ENABLED
TEST TIMEOUT OFF
DIAL/DBU PARAMETERS
TONE DIAL
AUTO DIAL #1
WAIT FOR DIAL TONE
WAIT DELAY 2 SECONDS
PAUSE DELAY 2 SECONDS
CALL TIMEOUT 30 SECONDS
ANSWER ON 1 RING
B-12
SPEAKER OPTION
VOLUME MEDIUM
ON UNTIL CARRIER DETECT
* Indicates variation from factory option set #1 (Information taken directly from manual)
B-13
UDS V.3400
Modem
Type
Model
Version
UDS V.3400
External
PROTOCOL OPTIONS
LAPM PROTOCOL DISABLED
MNP PROTOCOL DISABLED
BUFFER MODE DIRECT
DTE FLOW CONTROL DISABLED
DCE FLOW CONTROL DISABLED
XON/OFF PASSTHRU DISABLED
INACTIVITY TIMER OFF
BREAK OPTION #0
V.42 FAST DETECT DISABLED
DTE OPTIONS
ASYNC DATA
DTE RATE = 19200
8 BIT CHAR SIZE
NO PARITY
AT COMMAND SET DISABLED
IGNORES DTR
DSR IS NORMAL
B-14
DCD IS NORMAL
CTS FORCED HIGH
DTE FALLBACK DISABLED
OPTIONS RETAINED AT DISCONNECT
TEST OPTIONS
BILATERAL DIGITAL LOOP ENABLED
DTE LOCAL TEST DISABLED
DTE REMOTE TEST DISABLED
REMOTE COMMANDED TEST ENABLED
TEST TIMEOUT OFF
SPEAKER OPTION
VOLUME MEDIUM CHANGE
ON UNTIL CARRIER DETECT
B-15
Modem Settings
AT&F0
AT&A1
AT&D0
AT&H0
AT&K0
AT&N6
AT&R1
ATS0=1
ATS37=9
AT&W0
ATY0
B-16
Command Summary
(* indicates a change from the default)
*
*
*
B0
E1
F1
M1
Q0
V1
X4
Y0
&A1
&B1
&C1
&D0
&G0
&H0
&I0
&K0
&M0
&N6
&P0
&R1
&S0
&T5
&Y1
B-17
S-Registers
(* indicates a change from default)
*
*
S00=001
S037=009
B-18
(IMPORTANT NOTE:
Modem Settings
AT&F0
AT&A1 (Enables ARQ codes)
AT&D0 (DTR ignored)
AT&H0 (Flow control disabled)
AT&K0 (Data compression disabled)
AT&N6 (Forces connection at 9600 baud or modem hangs up)
AT&R1 (Modem ignores RTS)
ATS0=1 (Answer on first ring)
ATS37=9 (no effect)
AT&W0 (store to NVRAM 0)
ATY0 (defaults to profile 0 at power up)
B-19
Command Summary
(* indicates a change from the default)
*
*
*
B0
E1
F1
M1
Q0
V1
X4
Y0
&A1
&B1
&C1
&D0
&G0
&H0
&I0
&K0
&M0
&N6
&P0
&R1
&S0
&T5
&Y1
B-20
S-Registers
(* indicates a change from default)
*
*
S00=001
S037=009
B-21
Modem Settings
AT&F0
AT&A1 (Enables ARQ codes)
AT&D0 (DTR ignored)
AT&H0 (Flow control disabled)
AT&K0 (Data compression disabled)
AT&N6 (Forces connection at 9600 baud or modem hangs up)
AT&R1 (Modem ignores RTS)
ATS0=1 (Answer on first ring)
ATS37=9 (no effect)
AT&W0 (store to NVRAM 0)
ATY0 (defaults to profile 0 at power up)
B-22
ACTIVE PROFILE:
B0 E1 L0 M1 T Q0 V1 X4 Y0 &C1 &D0 &G0 &L0 &P0 &Q0 &R0 &S0 &X0 &Y0
\A3 %A013 \C0 %C1 %E1 \G0 \J0 \K5 \N3 \Q0 \T00 \V2 \X0 -J1 "H3 "S0 "O250
S00:001 S01:000 S02:043 S03:013 S04:010 S05:008 S06:002 S07:060
S08:002 S09:006 S10:014 S11:070 S12:050 S18:000 S25:005 S26:001 S31:000
STORED PROFILE 0:
B0 E1 L0 M1 T Q0 V1 X4 Y0 &C1 &D0 &G0 &L0 &P0 &Q0 &R0 &S0 &X0
\A3 %A013 \C0 %C1 %E1 \G0 \J0 \K5 \N3 \Q0 \T00 \V2 \X0 -J1 "H3 "S0
S00:001 S07:060 S11:070 S18:000 S23:027 S25:005 S26:001 S27:000 S31:000
STORED PROFILE 1:
B1 E1 L2 M1 T Q0 V1 X4 Y0 &C1 &D2 &G0 &L0 &P0 &Q0 &R0 &S0 &X0
\A3 %A013 \C0 %C1 %E1 \G0 \J0 \K5 \N3 \Q3 \T00 \V2 \X0 -J1 "H3 "S0
S00:000 S07:060 S11:070 S18:000 S23:011 S25:005 S26:001 S27:064 S31:000
TELEPHONE NUMBERS:
&Z0
&Z1
&Z2
&Z3
OK
Modem Settings
AT&F
ATB0
ATT
AT&C1
AT&D0
AT&K0
ATS0=1
AT&W0
AT&Y0
B-23
Command Summary
(* indicates a change from the default)
*
*
B0
E1
L1
M1
N0
Q0
T
V1
W0
X4
Y0
&C1
&D0
&G0
&J0
&K0
&Q#
&R1
&S0
&T5
&X0
&Y0
B-24
S-Registers
(* indicates a change from default)
*
*
S00=001
S037=009
B-25
Version
B-26
DNS
. .
. .
. .
Suffix
. . . .
. . . .
. . . .
.
.
.
.
:
: 192.168.10.2
: 255.255.255.0
: 192.168.10.1
13. Ping the radio IP address 192.168.10.1 and make sure it succeeds.
C-1
Note: This is needed only once. The "-p" remembers the settings even if the radio is powered
off, or the cable is disconnected.
2. To check that the connection is OK, ping as follows and make sure it succeeds.
ping 12.0.0.2
(12 is the CAI network address, 3 is the Radio ID, -w 5000 means wait five seconds for a
reply.)
4. To check that the connection to the remote RTU (via remote radio ID=3) is OK, ping as
follows and make sure it succeeds.
ping 13.0.0.3 -w 5000
(13 because to access the RTU, you specify the network ID 12 plus 1, -w 10000 means
wait five seconds for a reply.)
5. In order for the STS PC to communicate directly with the RTU via the above MotoTrbo
radio, in the STS Communication Setup set the Local Site IP address to 13.0.0.3.
Note: In order to download to other RTUs connected to MotoTrbo radios, it is recommended to
change the Local Site IP address in STS Communication Setup to that of the remote RTU.
This is because of MotoTrbos limited throughput.
C-2