Professional Documents
Culture Documents
ACE3600 STS Advanced Features
ACE3600 STS Advanced Features
The Motorola products described in this instruction manual may include copyrighted Motorola computer programs stored in
semiconductor memories or other media. Laws in the United States and other countries preserve for Motorola certain
exclusive rights for copyrighted computer programs including the exclusive right to copy or reproduce in any form the
copyrighted computer program. Accordingly, any copyrighted Motorola computer programs contained in the Motorola
products described in this manual may not be copied or reproduced in any manner without the express written permission of
Motorola. Furthermore, the purchase of Motorola products shall not be deemed to grant either directly or by implication,
estoppel, or otherwise, any license under the copyrights, patents or patent applications of Motorola, except for the normal
non-exclusive, royalty free license to use that arises by operation of law in the sale of a product.
Motorola, Inc.
1301 E. Algonquin Road,
Schaumburg, IL 60196 U.S.A.
Table of Contents
SCOPE ................................................................................................................................................................. 1
ACE3600 I/OS .................................................................................................................................................... 2
I/O Configuration .......................................................................................................................................... 2
I/Os and the Application ................................................................................................................................ 2
I/Os Hot Swap................................................................................................................................................ 3
I/O Module States .......................................................................................................................................... 3
Sleep Mode .................................................................................................................................................... 3
Hardware Tests.............................................................................................................................................. 4
Freeze Mode .................................................................................................................................................. 4
AUTOMATIC I/O RECOGNITION ........................................................................................................................... 5
POWER MANAGEMENT ....................................................................................................................................... 6
Configuration................................................................................................................................................. 6
Constraints..................................................................................................................................................... 7
SAFE FIRMWARE DOWNLOAD ............................................................................................................................. 8
FLASH FILE SYSTEM ........................................................................................................................................... 9
General .......................................................................................................................................................... 9
User Generated Flash Files......................................................................................................................... 10
Accessing Flash Files .................................................................................................................................. 10
Writing Flash Files ...................................................................................................................................... 11
Logging Flash Files..................................................................................................................................... 11
Flash File Headers ...................................................................................................................................... 11
Flash Files Diagnostics ............................................................................................................................... 12
ACCESSING DATABASE VARIABLES VIA COORDINATES .................................................................................... 13
Definitions ................................................................................................................................................... 14
EVENT DRIVEN SOFTWARE ............................................................................................................................... 16
Definitions ................................................................................................................................................... 16
Event Driven Mechanism............................................................................................................................. 17
Event Driven Tables .................................................................................................................................... 18
How to Use the Event Driven Software ....................................................................................................... 19
FAST EVENTS .................................................................................................................................................... 26
Events Triggers............................................................................................................................................ 26
Fast Event Definition and Configuration .................................................................................................... 26
Fast Event Scheduling ................................................................................................................................. 27
Enabling/Disabling Fast Events .................................................................................................................. 27
Monitoring of Fast Events ........................................................................................................................... 28
Fast Events Diagnostics .............................................................................................................................. 28
Testing Fast Events...................................................................................................................................... 28
Fast Events and Automatic Recognition ...................................................................................................... 29
NETWORK CONFIGURATION.............................................................................................................................. 31
Routing of Data Frames .............................................................................................................................. 31
Routing over Alternative Direct Link........................................................................................................... 32
Routing using Remote Failed Links Table ................................................................................................... 33
Using the Time To Live Counter.................................................................................................................. 34
MDLC OVER IP COMMUNICATION ................................................................................................................... 35
Overview...................................................................................................................................................... 35
Broadcast and Setcalls ................................................................................................................................ 36
i
New Features for MDLC over IP in ACE3600 ............................................................................................ 36
MDLC over IP/PPP Connections ................................................................................................................ 39
MDLC over IP/LAN Connections ................................................................................................................ 39
STS PC Communication Setup Options ....................................................................................................... 40
MDLC over IP Setup ................................................................................................................................... 40
MDLC over IP Site Paging.......................................................................................................................... 41
MDLC over LAN/Ethernet ........................................................................................................................... 42
MDLC over iDEN ........................................................................................................................................ 47
MDLC over Tetra ........................................................................................................................................ 60
MDLC over Standard Modem...................................................................................................................... 68
MDLC over GPRS ....................................................................................................................................... 71
MDLC over ASTRO IV&D .......................................................................................................................... 73
MDLC over Null Modem ............................................................................................................................. 81
Modem Configuration File .......................................................................................................................... 82
IP Conversion Tables .................................................................................................................................. 99
MDLC over IP Connection Verification .................................................................................................... 101
FIREWALL ....................................................................................................................................................... 103
Firewall Configuration.............................................................................................................................. 103
CLOCK FUNCTIONS AND SYNCHRONIZATION .................................................................................................. 104
RTU Clock ................................................................................................................................................. 104
Time Adjustment and Synchronization....................................................................................................... 104
Time Parameter Configuration.................................................................................................................. 106
Time Synchronization Diagnostics ............................................................................................................ 109
NTP Clock Synchronization....................................................................................................................... 109
Global Positioning System (GPS).............................................................................................................. 113
CORE DUMP .................................................................................................................................................... 117
MDLC ENCRYPTION....................................................................................................................................... 119
PROTOCOL ANALYZER .................................................................................................................................... 120
PID LOOP - PROPORTIONAL INTEGRAL DERIVATIVE ..................................................................................... 130
General ...................................................................................................................................................... 130
PID Function ............................................................................................................................................. 131
PID Table .................................................................................................................................................. 131
How to Use the PID................................................................................................................................... 133
PID Application Example .......................................................................................................................... 134
ENHANCED PID .............................................................................................................................................. 147
IRRIGATION ..................................................................................................................................................... 148
Irrigation Unit Types ................................................................................................................................. 148
STS Functions for Irrigation Units ............................................................................................................ 149
Tips on Using the STS for Irrigation.......................................................................................................... 150
ii
ACE3600 RTU-to-MOSCAD RTU Connection Using MDLC Protocol through RS485 ........................... A-6
ACE3600 RTU-to-PC Ethernet Port Direct Connection without Hub ...................................................... A-7
iii
Scope
This reference manual provides useful background information on ACE3600 advanced system
features, communication features, and specialized utilities and features.
• I/Os
• Automatic I/O Recognition
• Power Management
• Safe Firmware Download
• Flash File System
• Accessing Database Variables via Coordinates
• Event Driven Software
• Fast Events
The communication features include:
• Network Configuration
• MDLC over IP Communications (Static LAN, Dynamic – DHCP Client, or PPP)
• Firewall
• Clock Functions and Synchronization
The utilities include:
1
ACE3600 I/Os
I/O Configuration
The ACE3600 RTU can include up to eight I/O modules in any combination, arranged in a
single frame (rack) and numbered 1-8.
The 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.
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.
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.
If a ladder application is downloaded to the RTU and the I/O configuration associated with the
application does not match the I/O configuration in the unit, the application will not execute
and an error will be sent.
If a site configuration is downloaded to the unit with a working application, the unit will restart
and check the match between the I/O configuration associated with the application and the I/O
configuration in the unit. If the two do not match, the application will not execute and an error
will be sent.
If the system includes more than one site with the exact same I/O configuration, assigned to the
same application, the I/O Link information can be distributed from one site to the other sites.
During I/O link, the user can define input/output mask values to be used by the application if
the I/O module loses communication with the CPU.
If an I/O module is replaced by another module of a different type, the I/O link association will
remain for any I/Os which are the same (e.g. DI in Frame 0 Module 1 linked to IN_1). For
those I/O whose types have changed, a popup will be displayed explaining that those links will
be erased (e.g. DI in Frame 0 Module 4 is now a DO).
• Running: The I/O module in the slot matches the one in unit’s 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
unit’s site configuration. (In this case the application cannot run.)
• Mode Selected: e.g. Freeze mode or Sleep mode. (Determined by user or application.)
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.
3
Hardware Tests
The RTU’s 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.
4
Automatic I/O Recognition
The site configuration of an ACE3600 RTU includes the definition of all I/O modules in the
unit. In legacy MOSCAD systems, the user manually defined each module in each RTU using
the Site Configuration tool and then linked the physical I/Os to the definitions in the single-
and multiple-column tables using the Application Programmer tool.
With the Automatic Recognition feature, the ACE3600 RTU identifies the actual hardware (I/O
modules only) components in the unit when starting up and builds the initial site configuration
accordingly. This site configuration is based on the default site settings and the unique module
type ID number associated with each I/O module.
The Automatic Recognition feature saves time for the system definer who merely sets the
‘Enable auto I/O modules recognition at startup’ field (disabled by default) in the STS and
powers on the RTU. Once the initial I/O module configuration is determined, the site
configuration is uploaded using the Upload New Site command from the System menu. For
more information, see the Uploading a New Site to the STS section of the ACE3600 STS User
Guide. Further site configuration or advanced I/O configuration may be required. For more
information, see the Customizing the Configuration of a Site section of the ACE3600 STS User
Guide. Once all changes are made, the new site configuration can be downloaded to the unit.
For more information, see the Downloading to a Site section of the ACE3600 STS User Guide.
Note: In an RTU to which no site configuration has been downloaded, a default configuration
exists, with Automatic Recognition enabled. When uploading from an RTU to which no site
configuration has been downloaded, the Site Upload Form will list Default Site Configuration
instead of Site Configuration. The configuration of the inserted I/O modules and plug-in ports
PI1 and PI2 will be retrieved.
The RTU also identifies the module type automatically when an I/O module is inserted into a
slot (hot-swap) in a powered-up RTU which is configured for Automatic Recognition. If an
application is running, the application will ignore the newly inserted I/O module. When the
RTU is restarted, the application will relate to all I/O modules. After restart, the site’s I/O
configuration will also reflect the change in the I/O modules.
If a conflict arises between the I/O module configuration of an RTU associated with the
application and the actual I/O module configuration (as recognized by the Automatic
Recognition feature), an error will be sent to notify the user of incompatible definitions, and
the application will relate only to those modules which have no conflict.
When automatic recognition is set in the site configuration, the user cannot define I/O modules.
If the site configuration includes at least one I/O module, the user cannot enable automatic
recognition. In each case, the STS prompts the user to choose one option or the other.
5
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 RTU’s 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.
• 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 module’s 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.
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 manager’s message queue. For details, see Appendix A: Site Configuration
Parameters in the ACE3600 STS User Guide.
6
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 don’t want the process to wait for a response to the user’s request. Therefore, such a
request returns immediately and the user must check the hardware indications, (i.e. Get() the
hardware’s 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.
7
Safe Firmware Download
A primary feature of the ACE3600 is the Safe Firmware Download. This feature ensures that
remote download of firmware to an RTU will not cause the RTU to become unreachable. This
feature is based on the concept that after new firmware is downloaded to an RTU and it is
restarted, the RTU should be able to communicate with the PC host which downloaded the
firmware. If it will not be able to communicate with the remote PC host, then RTU will roll
back to its previous firmware. This protects the RTU from a situation where a flawed firmware
image is downloaded and it becomes impossible to communicate with it remotely.
When an ACE3600 RTU is delivered from the factory, it contains the current firmware version
(primary image) in the Flash memory. It also contains a minimal bootstrap image in the Flash
memory, including the VxWorks operating system and a basic ACE application. The bootstrap
image enables you to start up the unit and download new firmware (in the unlikely event that
the unit cannot start up correctly with current loaded firmware, application and files.)
When the ACE3600 RTU is running, a new firmware version can be downloaded using the
ACE3600 STS Download feature from a remote/local host over the MDLC or IP network. In
the Download window, in the System File Settings, the ‘Evaluate request’ parameter (by
default enabled) instructs the unit to evaluate the newly downloaded image before making it
the primary image. Evaluation means the unit has received an evaluate request and then sends
an echo to the host STS within a period of five minutes after the new firmware download.
(The unit is rebooted 30 seconds after the end of the firmware download. The Evaluate request
is transmitted from the STS to the unit approximately every 30 seconds up to the five minute
limit).
If the downloaded firmware is evaluated and found to be problematic, the RTU will restart and
roll back to the earlier, robust, burned image, and a message will be displayed on the
Downloader screen. If the downloaded firmware is found to be sound, it will be burned to the
Flash memory and become the primary image.
A similar checks exists for site configuration files, where the system checks every new site
configuration that is downloaded. If there is a discrepancy between the I/O site configuration
in the ladder application and in the RTU, an error will be logged and the system will revert to
the previous configuration. See the Downloading to a Site section of the Operation chapter of
the ACE3600 STS User Guide.
Note that firmware files are large and may take a long time to download at low communication
speeds.
8
Flash File System
General
Information in the ACE300 RTU flash memory is organized and maintained as files in a flash
file system (Motorola Flash File System-MFFS). User flash files are created when the user
configures/administers the ACE3600 RTU using one of the STS utilities. In general, the user
will interact with these files via the STS GUI and the specific utility (e.g. Network Manager,
Phonebook, etc.) For those user files in flash which require handling outside the STS, high-
level file operations have been provided in the ACE3600 RTU ‘C’ Toolkit. These file
operations handle file pointers and low-level read/write operations and were designed to save
the user time and effort. For more information, see the ACE3600 RTU ‘C’ Toolkit User
Guide.
Note: System flash files cannot be accessed by the ‘C’ application. Burned system software
stored as a consecutive block instead of a flash file.
Associated with each user flash file type is a File ID, as shown in the table below.
9
File ID Description File ID Description
32 IP Conversion Table
In addition to user flash files, the user application can create log flash files (File ID #55)
during runtime.
The File ID associated with ‘C’ application parameter files is determined by the choice of file
type in the STS Add-Ons Manager, as shown in the figure below. The file name extension or
suffix (e.g. .dat, .txt, etc.) is determined by the user. Most file types can have one instance in
the flash at any one time. ‘C’ Application Parameters files (with and without reset) can have
more than one instance (e.g. MyCfile.dat and MyCfile.txt).
Therefore, files of a file type which can have multiple instances in the flash (i.e. ‘C’ data
parameters) with different file name extensions (e.g. .dat, .txt, etc.) that are downloaded using
the *.* extension, should be given different filenames; otherwise the second instance of the file
will override the first instance which was just downloaded previously.
In the event that a file download fails, the temporary file may remain in the flash memory, to
be overwritten the next time a file of that type is downloaded.
To clean up extraneous files from the flash, use one of the Erase Flash options in the ACE3600
STS Downloader utility.
Note: It is not recommended to create very large user files (greater than 1MB). Instead use
several smaller files.
An advanced parameter which can be set in the STS site configuration determines the
Maximum size of Flash memory for user logging and the percentage of the flash to be used for
logging flash files.
The ACE3600 RTU ‘C’ Toolkit provides a number of specialized functions for performing
operations on user logging flash files, such as reading, writing, appending and removing
logging flash files. Information such as whether the logging flash file exists, the status of the
logging flash, the amount of free/used logging flash. For more information, see the ACE3600
RTU ‘C’ Toolkit User Guide.
11
Logging flash file headers are added automatically by the system. The logging flash services
provided by the ‘C’ Toolkit return the size of the file as well as the size of the file header.
If after downloading a ladder application to the RTU, the site configuration information stored
in the RTU flash conflicts with that defined in the ladder application, the MFFS diagnostic will
list both files (although the ladder database and rungs will not be used.)
Under certain circumstances files are listed in the MFFS diagnostics but not used during
runtime due to integrity failures. For example: If the ladder was downloaded with the ‘Load
Only’ ladder application setting and the number of differentiators used in the rungs is different
than in the previously used ladder, then the new burned ladder will not be used.
Software diagnostics on the logging flash files can be retrieved using the SW Diagnostics,
Device LOGFLAS. Level 0 provides information about the logging flash status (current and
previous file and operations). Levels 1 and 2 provide information on the logging flash queue,
and Level 3 provides information on the buffers in use.
The list of application files in use that were loaded from Flash memory to RAM memory can
be retrieved using SW Diagnostics, Device FFILES Level 0.
12
Accessing Database Variables via
Coordinates
One of the most important features of the RTU is its database structure and concept (refer to
Appendix C: Database Tables and Types in the ACE3600 STS User Guide.) The RTU database
is divided into reserved and user-defined variables/constants, arranged according to various
data types (such as discrete inputs/outputs, value inputs/outputs, timers, parameters, etc.)
The application database is built as a set of tables, where each table defines a group of devices,
each row defines a separate device and each column contains a specific device data. The table
entries are assigned user-significant names, such as PUMP1.
Since database variables are assigned meaningful logical names, it is very easy to build,
understand and modify the database.
Two functions, FETCH and STORE, are available for accessing database variables also via
coordinates. Every database variable can be accessed by the following three coordinates:
• Y coordinate (Y=0,1,...,249) is the row number in the user table that appears under the
index (Ind) column
This way of accessing database variables may be useful for mapping the database of one RTU
into another RTU using user protocols (which use coordinates to access database variables
rather than logical names).
13
6BAccessing Database Variables via Coordinates
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 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:
14
6BAccessing Database Variables via Coordinates
• 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 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
P fl1
Y #4
Store
( CALL )
Table #
15
Event Driven Software
Some applications, especially electrical ones and process control, have to deal with fast
changes caused by various events or follow these events with precise delay. The RTU provides
you with the necessary database types and special functions in order to deal with such events.
These functions allow you to get information on the change that has occurred (database
coordinates, data, and time stamp) and activate a specific process accordingly, rather than
polling the database. It also allows you to activate "fast" timers (shorter than Scan time) upon
events.
The time stamp can also be retrieved without waiting for an event to take place and stored in
the Ladder Database.
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:
16
7BEvent Driven Software
• 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.
• TAG+EVENT – for time-tagged and event-driven COS. A combination of the above two
types.
When calling the GtEvnt function, the event is transferred to the Event-Driven database table
(PRMEVENT table), while the rack (frame), module, and input numbers are translated into
X,Y and Z coordinates, (where: X=column no., Y=row no., Z=table no.). Simultaneously, the
corresponding table in the database is updated according to the change that has occurred.
The event's time (date and time) is written to the TmMost and TmLeas columns in the
PRMEVENT Table). These are two real type parameters, that represent the event's time as
follows:
TmMost 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).
17
7BEvent Driven Software
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.
3 - The RTU's time was set by the STS (using the STS Date & Time utility or Sync
command).
5 - The existence of the time's parameters in the TmMost and TmLeas columns, is a result of
calling the Time function.
18
7BEvent Driven Software
The two columns at the right of the PRMEVENT Table, show the time and date (TmMost and
TmLeas), in a readable format. The user may read these parameters on-line, by activating the
Monitor mode in the Application Programmer.
• 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.
19
7BEvent Driven Software
StEvnt
(1) ( CALL )
#2
GtEvnt
(2) ( CALL )
__Typ __Tbl
Procs1
(3) = ( JSP )
#0 #9
__Typ __Tbl
Procs2
(4) = ( JSP )
#0 #11
__Typ __Tbl
Procs3
(5) = ( 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.
20
7BEvent Driven Software
I
(1) ( MOVE )
__Row
#1
Inp1, I Inp2, I
__Typ
Send2C
(4) ( JSP )
#2
(5) ( RET )
Rung 1: This rung stores the row number (___Row) in the I index.
Rung 2: If it is an event (not caused by a timer; ___Typ=1), and Inp1,I is not equal to
Inp2,I, then the system jumps to the Send2C subprocess to send specific bits to
the central.
Rung 3: If it is an event (not caused by a timer; ___Typ=1), and Inp1,I is equal to Inp2,I,
then the ___Val variable gets the value of 30 (thus, setting the timer to 300 msec),
and the SetTmr function is called to activate the timer. Note that the parameters of
the event are still kept in the PRMEVENT table.
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.
In the MAIN process, you should add appropriate rungs to perform a loop, that checks if there
are additional events in the queue.
21
7BEvent Driven Software
The following rung checks the analog value ANA1, and according to its value, activates the
Time function. This option allows the user to get the occurrence time of an analog event.
ANA1
Time
( CALL )
500+
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:
Mv1, Mv2 (for TmMost) and Lv1, Lv2 (for TmLeas) must be consecutive.
22
7BEvent Driven Software
C Mv1
P TmMost
Y #4
C Lv1
P TmLeas
Y #4
Rung: r6
Mday
( MOVE )
Mv1
Mday
( LSR )
#8
A Mmonth
N Mv1
D #255
MYear
( MOVE )
Mv2
MYear
( LSR )
#8
A Mhour
N Mv2
D #255
Rung: r7
23
7BEvent Driven Software
Mmin
( MOVE )
Lv1
Mmin
( LSR )
#8
A Msec
N Lv1
D #255
Mmsec
( MOVE )
Lv2
Rung: r8
24
25
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.
The actual triggers and the high priority fast processes are defined using either the STS
Application Programmer (ladder diagram) or the ACE ‘C’ Toolkit (‘C’ code).
IMPORTANT: Fast events should not be operated both from a ladder diagram and ‘C’ code.
One event can trigger more than one fast process, and the same fast process can be activated by
more than one trigger.
The application can choose to activate the fast process(es) after a certain delay.
26
8BFast Events
The user is responsible for managing the fast events. If an error message is received that a fast
event process is consuming too many system resources, the user should act accordingly. The
system will not take any action other than reporting an error message.
T Proc T Proc
E Trig D Trig
N P1 S P1
where Proc is the process to be operated, Trig
is the trigger (PB pressed, DI change of state, or delay), and P1 is the trigger value (i.e. PB2,
DIx, # of delay seconds). See the application database Trigger States constants table for the list
of trigger definitions.
Notes:
• 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 Proc1
E FE_DI_COS
N DI,x
enables process Proc1 after DIx goes to state DI-COS.
T Proc1
E FE_PB_UP
N PushB2
enables process Proc1 after pushbutton PB2 is
pressed.
27
8BFast Events
T Proc1
E FE_DELAY
N #10
enables process Proc1 after delay of 10 seconds.
When a fast process is monitored via the Application Programmer, the actual values of the
symbols received from the RTU during on-line operations are displayed. When a fast process
is monitored via a C application, system diagnostics (MOSCAD_get_sw_diag()) and user-
defined diagnostics (DCF6) can be used to keep track of the triggers, the time delays and the
processes’ execution (e.g. average/maximum runtime.)
Monitoring a rung with a call to the TEN (Trigger enable) operator will not provide any
meaningful information. Monitoring a fast process is not meaningful either, because the
monitor process has lower priority than the fast process. Therefore, software diagnostics are
the more useful way to follow the results of fast events.
Level 0 provides general information about the F_EVNT device configuration parameters and
overall execution (e.g. whether fast events are supported by the system software.)
Level 1 provides information about the last fast event, including errors that may have occurred.
At this level, you can verify that a delay trigger occurred (after the fact.) Errors that occurred
will also be reported to the error logger at the end of the fast process execution.
Levels 10, 11 provide information about DI triggers, and Levels 20, 21 provide information
about pushbutton triggers.
Note: If the application includes a jump from a fast process to another rung, the compiler will
produce a warning that this could lead to an infinite loop.
28
8BFast 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.
2. In the Site Upload Form, select Site Configuration only and click on Upload.
3. In the popup Upload Notification dialog, click Yes to set the I/O Auto Recognition flag to
false in the site. This will enable the I/O configuration information to be saved.
4. Using the Application Manager, open the ladder application and define the database
variables required for the DI triggers.
5. In the application rungs, call the TEN/TDS operators with the trigger variables.
6. In the I/O link table, link the trigger variables to the actual DIs.
29
8BFast Events
30
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
network’s 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.
The STS SW Diagnostics device “NSTOCK” (Levels 2, 3) provides the full list of data links
(as defined in Network Configuration), and adds the status during runtime. The transmitting
node will search for a proper path (sequentially, starting with the first entry) until it is
successful. If some of the links are in “fail” state, the node will try the first link that is in
working order. If all possible links are in “fail” state, it will try the first path. If the
transmission fails, the frame is discarded, unless the “Remote Fail Link Awareness” feature is
enabled in the Site Configuration. (See Routing using Remote Failed Links Table below.)
31
9BNetwork 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.
All relevant links in the example below were defined in the Network Configuration and
downloaded to the units. This can be seen using the Software Diagnostics NSTOCK device
(Level 3). RTU100 will choose a link which is not failed for communication with RTUs 1-99
(as will be done in communication between RTU4 and RTU 88.) Thus if RTU100 is unable to
initiate communications with RTU2 over the radio link, due to a radio failure, it will
automatically attempt to communicate using the dial link. If no alternative links exist, or if all
fail, then the transmission will fail. In the case of a failed direct link (when an alternative
direct link exists), the recovery mechanism described above in Routing of Data Frames is
performed, according to the parameter settings in the site configuration.
RTU 1
RTU
101
RTU 2
L2
RTU RTU 3
PSTN
100
RTU 4
RTU 5
.
.
RTU 99
Routing over Direct Link is only possible with ACE3600 and the STS. If you upgrade old
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.
32
9BNetwork Configuration
In current systems, when a system has a network structure which contains a loop, an alternate
routing scheme is feasible, i.e. the failed link can be bypassed and the frame can be transmitted
to the target unit. A node may also be enabled to choose an alternative path if the destination is
on one of its direct links. The routing is done using the data stored in the Remote Failed Links
Table. (The table can be viewed using the Software Diagnostics Level 5 device NSTOCK).
This data is collected by the transmitting unit if the Remote Failed Link Awareness option is
enabled.
A node that is not the originator of the frame that fails to forward an MDLC frame to the next
site, will return the frame to the originator (source) with additional information about the failed
link and site. A frame is returned only when no further routing is possible via all available
links. The site, the originator of the frame, and any site along the route all record the failed
links information in the Remote Failed Links Table. When a frame is to be routed by an RTU,
the failed links information from this table is used, as described in Routing of Data Frames
above.
If the ‘Do not route returned frame’ parameter in the site configuration is disabled, the returned
frame can be re-routed by the frame originator (before the application retry) using another path
from the network data bank, which does not include any failed links.
Failed link information is deleted from the Remote Failed Links Table upon link restoration
(when actual communication acknowledgement is received) as described above, or upon
timeout, as set by the ‘Remote Failed Links Table entry timeout’ advanced parameter in the
site configuration. When a communication to a failed link that is listed in the Remote Failed
Links Table is restored by actual communication, an additional transmission is generated to all
sites, notifying them to remove that entry from their table as well.
This feature can be enabled in the STS site configuration in the advanced parameters under
Network.
By default, routing using the Remote Failed Links information is disabled in the Site
Configuration making network behavior compatible with previous versions. To enable the
feature, the “Remote Failed Links Table size” must be greater than 0, and the “Time to Live
Preset Value” must be greater than 0. To enable the originating unit to resend the information
before the retry, the ‘Do not route returned frame’ parameter must be set to “NO”. (Avoid
using this unless necessary.)
If an RTU identifies more than one failed link during the same frame transmission, it updates
the Remote Failed Link Table with a general failure code, rather than specifying all the various
failed links. (The failed link entry will be marked with Link ID 255.) If any one of these links
is restored, the entry is removed from the Remote Failed Link Table and all failed links are
considered restored.
In order to prevent endless transitions between RTUs until a failed link is restored, set the
‘Remote Failed Links table entry timeout’ parameter in the site configuration to a value greater
33
9BNetwork Configuration
than the maximum of link retry timeouts (‘TX to failed RTU’ parameter) defined for all of the
RTU’s 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 looped shape 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.
The Time To Live preset value is set in the STS site configuration. (See the ACE3600 STS
User Guide.) By default it is set to zero and the feature is disabled. This makes the network
compatible with previous versions. To enable the feature, set the value to be greater than twice
the longest path in the network (maximum numbers of nodes in the entire longest path).
The Time to Live feature is activated in the STS site configuration in the advanced parameters
under Network.
IMPORTANT: When setting this feature, all RTUs in the system must have a firmware
version that supports this feature.
34
MDLC over IP Communication
Overview
ACE3600 RTUs can use IP (Internet Protocol) technology to interface to advanced radio
infrastructure (e.g. TETRA or GPRS) and to standard private IP networks. Most benefits of the
MDLC protocol are preserved. MDLC and IP networks can be integrated in the same system,
as networking properties are preserved. MDLC applications need not be modified as the lower
layers of the protocol support IP.
MDLC packets to be transmitted are enveloped inside UDP/IP datagrams and sent between
remote RTUs or between an IP Gateway and an RTU over UDP port 2002. UDP Port number
is configurable for each port.
The ACE3600 RTU can have several MDLC over IP ports, each identified by its own link ID:
MDLC over RS232 PPP ports, and MDLC over LAN/Ethernet ports that can have static or
DHCP addressing modes. In some cases it is required that an MDLC over IP port have more
than one link ID.
Each MDLC over IP port has its own unique link ID. An IP address identifies each port, and is
set by the user in a static LAN port. For DHCP and PPP this address is learned automatically,
and the user does not need to define it.
A PC running STS can be connected to one of the RTU ports, to one of the serial ports of the
IP Gateway, FEP or to the Ethernet.
1. ACE3600 RTU port connected to a packet data radio/modem over PPP (Point to Point
Protocol). The RTU can act as a remote unit or as a front end serving a SCADA control
center (over PLC or user port).
2. ACE3600 RTU port connected to a LAN through one of its on-board or plug-in Ethernet
port. A direct LAN connection exists between the Ethernet port and the radio
infrastructure. The RTU can act as a remote unit or as a front-end serving a SCADA
center. This port can be configured as static LAN or as DHCP LAN.
3. ACE3600 FEP connected to LAN. An FEP serves as a front-end for a TCP/IP based
SCADA central and enables it to communicate with remote RTUs. The FEP can use
MODBUS over RS232 or any other propriety protocol over RS232 or LAN to
communicate with the SCADA. If a LAN is used, the ‘C’ Toolkit socket (user protocol
over IP) functions provide that functionality. The ACE36000 RTU can use a direct LAN
port connection with other RTUs over the radio infrastructure. It can also be connected
with a packet data modem/radio over PPP. For information on the ‘C’ Toolkit socket
functions, see the ACE3600 RTU ‘C’ Toolkit User Guide.
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.
36
10BMDLC over IP Communication
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.
In the IP conversion table, set a host name instead of a numeric IP address for a specific site +
link ID. The link ID, for example LINE5, identifies the port/IP connection of that site.
To enable this, the port needs the list of DNS servers for that MDLC over IP port. This step
can be automatically learned. The list must be set only for an Ethernet port configured as Static
IP address mode. An Ethernet port configured as DHCP or an RS232 port configured as PPP
automatically learns this list from the network, and the user does not need to set them.
Note: Some PPP connected radios such as TETRA MTM700 and ASTRO IV&D radios do not
provide DNS information. These systems usually do not use host names either, but if
necessary, the user can set the list of DNS Servers in the port configuration.
The FQDN option for an Ethernet port configured as DHCP updates the DNS servers when a
new IP address is allocated to it by DHCP. The user need only set the full host name of that
port. A warning is logged if the router/DHCP server does not support this option,
Note: It is possible to define an NTP server with a full host name (e.g. www.mysite.com). To
do so, the user must set DNS servers for this port, either statically, or from a DHCP server or
PPP modem.
37
10BMDLC over IP Communication
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 FEP’s 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.
Note: This feature can also be used in an FEP connected to the CEN of ASTRO IV&D, where
it is required for one RTU connected to a radio to communicate with another RTU.
For more information on attaching files using the STS Add-Ons Manager and downloading
files to the RTU, see the ACE3600 RTU User Guide.
Note: If you try to attach the same modem configuration to more than one port in the same
site, an error will be displayed. In this case, simply rename the file name.
38
10BMDLC over IP Communication
• 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. 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.
39
10BMDLC over IP Communication
1. Serial port connection - The serial port of the PC is connected to the computer port of an
RTU or IP Gateway.
2. Ethernet port connection – The PC’s Ethernet connection is connected to a LAN via an
RTU or IP Gateway. In the Comm Setup utility, select Ethernet Port and set the Local IP
Address to that of the RTU or IP Gateway.
3. Peripheral Interface connection – The PC’s serial port is connected to a phone or a modem.
The STS can communicate with other RTUs/IP Gateways which are attached to
radio/modems. In the Comm Setup utility, select Ethernet Port and set the Local IP
Address to that of such an RTU. Note: The user must get access permission from the
provider to communicate with that RTU. A RAS connection such as Standard Modem
must be set up in the PC. Run the Phonebook Editor/Dialer and "dial" into the
modem/radio before running STS.
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.
1. Define the site configuration for either on-board serial or plug-in port, according to the
options below:
For IP connections via RS232/PPP, the port type will follow the form of:
RS232, Async, Connection Type, Connection Mode
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
40
10BMDLC over IP Communication
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.
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.
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 in seconds, Poll interval in seconds, 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.
41
10BMDLC over IP Communication
The figure below illustrates an example of a SCADA system with IP Gateway and ACE3600
RTUs connected to Ethernet LAN:
SCADA
Central
STS
Ethernet 1
LINE 1
IP
RS-232 Gateway
STS
IP
Network
Ethernet 2
Ethernet 3
10BaseT 10BaseT
10BaseT
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 Gateway’s 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
42
10BMDLC over IP Communication
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.
In DHCP address mode, the user is only required to set the link ID for this port. If DNS
servers are required there is no need to set them, since they are learned from the network. If
NTP servers are required, the user must set them since they are not learned from the
network.
As an option, user can set a full host domain name for an Ethernet port that is configured as a
dynamic DHCP client. Each port should be set with a different name. This option allows the
network DNS servers to be updated when the DHCP server changes its IP address, keeping its
name up to date. This is called FQDN and is not always supported by the DHCP server (in this
case a warning is logged.)
In order to comply with IP networks standards, all configuration methods described in this
chapter are based on standard procedures used in IP networks.
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.
43
10BMDLC over IP Communication
This parameter is optional, in case IP Conversion Table has addresses beyond 155.9.199.xxx
for that port’s 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.
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).
Default: LINE 1
DNS Servers As an option the user may enter up to three DNS servers.
This step is only necessary if using host names for this
specific link in the IP conversion table.
Ethernet ports of the ACE3600 RTU can be configured dynamically using DHCP. Each one of
these ports can be configured as a DHCP client.
44
10BMDLC over IP Communication
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.
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 As an option 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 1 millisecond
if connected to the same network, and a tenth of a
millisecond if connected to different networks.
The NTP server can be an internet server, or an ACE3600
FEP. If it is an FEP it is up to the user to set its clock. Note
that in ACE3600 a 1 millisecond drift exists every 2
minutes, if not connected to external sync source such as
NTP or GPS.
45
10BMDLC over IP Communication
The following parameters are common to all Link names configured for this LAN port. They
are the same for DHCP client and for Static LAN.
46
10BMDLC over IP Communication
47
10BMDLC over IP Communication
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 modem’s 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
LINE 1 Routing
Net
IP
RS-232 Gateway
STS
Home
iDEN Agent
infrastructure Interface
Router
Mobile
Base Data
Station Gateway
LINE 1
48
10BMDLC over IP Communication
iDEN 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).
Paging is a “wake up call” which causes a dormant/idle modem to wake up and allocate
appropriate RF resources needed to communicate over a packet data network. Once the packet
channel has been accessed, the paged modem will become active for a limited amount of time.
While in active state, the modem can only handle packet data, and cannot get any voice
dispatch calls. It is important to note that the iM1000 modem only handles data and no
voice/dispatch calls.
Note: Because of the overhead involved in paging and accessing a channel, there will be a
certain delay before the modem becomes active and can receive data. The length of the delay
49
10BMDLC over IP Communication
depends on the topology and state of the network. This may be relevant for some applications
involving data sent from one RTU to another.
Note that a paging mechanism in the MDLC protocol makes MDLC over IP more reliable.
Setting these parameters in the Advanced Link layer is explained above in MDLC over IP Site
Paging above.
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.
50
10BMDLC over IP Communication
51
10BMDLC over IP Communication
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.
52
10BMDLC over IP Communication
The following parameters are common to all Link names configured for this port.
53
10BMDLC over IP Communication
54
10BMDLC over IP Communication
55
10BMDLC over IP Communication
56
10BMDLC over IP Communication
Other parameters are set by the iDEN infrastructure over the air when the modem is powered
up. If the configuration fails, this may be due to a problem with the iDEN infrastructure. In
this case, users should consult with the iDEN network operator.
If one of the modem’s internal settings (i.e. the service key used for fraud prevention/
authentication, number assignment module, network ID, or passcode) needs to be modified,
this can be done locally, using the Applet IX1000 software. The Master Reset operation may
also be required to change the modem identification number and enable the iDEN
57
10BMDLC over IP Communication
infrastructure to reset parameters in the modem. These changes should only be performed in
coordination with the technical support group.
Note: The set of AT commands listed below is suitable for iM1000 modem. For that purpose,
an appropriate modem configuration file can be downloaded to RTU. (For details, see Modem
Configuration File below.) For a complete description of the AT commands, refer to Applet
user manual.
AT&D0 – Instruct the modem to ignore DTR, since the RTU does not support it.
AT+WV175=10 – Set the modem’s session timeout to 10 seconds, i.e. after 10 seconds from
the last communication over the air, the modem becomes idle and needs to be paged in order to
receive data. Setting it to 0 makes the session state permanent.
AT+WS182=3 – Communication over the air will not be compressed. Setting this parameter to
1 will compress data over the air.
Note: If needed, before the modem is set to online mode, it is reregistered using the commands
AT+WPDEREG and AT+WPREG. This occurs only when the RTU powers up, and after the
modem has been deregistered from the system.
The modem is restarted using this AT command after several unsuccessful attempts to
configure or register it (refer to Number of configuration attempts to reset radio/modem). This
command is also issued by the RTU when connecting to the modem for the first time.
58
10BMDLC over IP Communication
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.
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.
59
10BMDLC over IP Communication
The connection to Tetra can be made via LAN or via radio. An IP Gateway or an RTU with an
Ethernet plug-in or on-board port can be connected to a LAN. In Tetra terms, an RTU that is
connected through LAN is called a LAN RTU. An RTU that is connected to a radio is called a
PEI (Peripheral Interface) RTU. A PEI RTU is connected to a radio through RS232 using
standard PPP (Point to Point Protocol).
In the figure below, the SCADA central and IP Gateway are connected via LAN to Tetra
infrastructure. Each RTU has an MTM700 radio connected to its MDLC over IP Port using
PPP. A unique IP address is assigned to each RTU according to its radio’s identifier (SSI). All
communication between RTUs and the IP Gateway involve 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
LINE 1 Routing
Net
IP
RS-232 Gateway
STS
Tetra
Infrastructure
SW MI
LINE 1
Tetra Tetra
MTP700 MTP700
radio radio
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
60
10BMDLC over IP Communication
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:
61
10BMDLC over IP Communication
DNS Servers 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.
NTP Server 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.
62
10BMDLC over IP Communication
Number of Default: 2.
configuration attempts Range: 0 to 255.
to reset radio/modem
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.
Wait time after Reset Default: 7 seconds.
radio [sec] 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.
63
10BMDLC over IP Communication
64
10BMDLC over IP Communication
65
10BMDLC over IP Communication
66
10BMDLC over IP Communication
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.
67
10BMDLC over IP Communication
AT+WS45=4 – Instruct the radio to initiate PPP with the RTU when getting the ATD
command.
A modem configuration file can be downloaded into the RTU specifying the exact command
set needed by the modem/radio. A default AT command set is used in case this file is not
downloaded. The same concept is used for circuit data modem over dial port.
The following modems/radios may be configured using a modem configuration file. Files for
this purpose are provided in the C:\STS<version>\config directory.
Connection to Standard modem is made using PPP over the operator infrastructure. Since the
operator infrastructure connects to LAN as well, a LAN-connected RTU can communicate
directly with these RTUs over that infrastructure, if enabled by the operator.
Some modem vendors such as Siemens MC75 have an internal IP address for PPP connection.
This address should be unique per RTU. If so, only one modem of the same vendor can be
connected to RTU, since they all have the same IP address. Other vendors’ modems such as
Motorola g18 do not have an internal IP address; in this case several MDLC over IP ports can
be configured to connect with them.
To verify if more than one modem can be used, try to connect two modems and see if you get
an error message: IP Address in use by other ports.
68
10BMDLC over IP Communication
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.
69
10BMDLC over IP Communication
AT&D1 – Instruct the radio/modem to check if DTR is active. When the RTU deactivates
DTR, the radio/modem will reset its port, and the PPP connection will terminate.
AT+WS45=4 – Instruct the radio/modem to initiate PPP with the RTU when getting the ATD
command.
70
10BMDLC over IP Communication
In the figure below, the SCADA central and IP Gateway are connected via LAN to the GPRS
infrastructure. Each RTU has a G18 GPRS/GSM modem connected to its MDLC over IP Port
using PPP. A unique IP address is assigned to each RTU according to its modem identifier
(IMSI). All communication between the RTUs and the IP Gateway involves sending
datagrams in packets over the Internet (IP). The GPRS infrastructure routes those packets
directly between two RTUs, or between IP Gateway and an RTU. A PC running STS can be
connected directly to an RTU or operate remotely over IP.
SCADA
Central
Ethernet
IP RTU
Gateway RSlink1 g18 GPRS
Packet Data
modem
GPRS
infrastructure
LINE 1
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).
71
10BMDLC over IP Communication
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.
Note that before downloading the modem configuration file for GPRS, you need to change its
APN according to your operator instructions. The APN (Access Point Name) is an address such
as intranet.motorola.co.il in the following string under [ConfigurePD] section:
<AT+CGDCONT=1,"IP","intranet.motorola.co.il","0.0.0.0",0,0><OK><4>
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 tool, set up either PI1/PI2 or SI1/SI2 as RS232, Async, PPP. Select
Standard Modem:
72
10BMDLC over IP Communication
The Advanced parameters are the same as described above for MDLC over Standard Modem.
The connection to ASTRO IV&D can be made via LAN or via radio. The LAN is called a CEN
(Customer Enterprise Network). An IP Gateway or RTU with an Ethernet port can be
connected to the CEN. On the other end, an RTU can be connected to an ASTRO IV&D radio
via an RS232 data cable. Note that a specific codeplug which supports the data option must be
used when programming them.
Note also that mobile radios such as XTL5000 can work in Analog mode on Trunk II with a
DPSK modem. This has nothing to do with MDLC over IP; both the radio and the RTU are
configured differently.
In the figure below, the SCADA central and IP Gateway are connected via LAN to a Customer
Enterprise Network (CEN). The CEN is connected via a border router gateway to the ASTRO
IV&D infrastructure. An RTU, running MDLC over IP protocol over PPP, is connected via
XTL5000 radio using an RS232 data cable. A unique IP address is assigned by the GPRS
Gateway Support Node (GGSN) to each RTU according to its radio individual unit ID (UID),
such that when a frame is transmitted from the CEN to that IP address, the Packet Data Router
(PDR) and Radio Network Gateway (RNG) transmit it to the appropriate radio.
Unlike other infrastructures such as iDEN and TETRA, this IP address and radio unit ID
cannot be retrieved for diagnostics from the radio. Instead a dummy IP Address is provided by
the radio as configured in its CPS.
73
10BMDLC over IP Communication
SCADA
Central
Ethernet
Customer
LINE 1 Enterprise
Network
IP
RS-232 Gateway
STS
Base RNG
Station
LINE 1
74
10BMDLC over IP Communication
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.
75
10BMDLC over IP Communication
If the RTU needs to log into the infrastructure/radio using a user name via PPP connection,
specify the following parameters.
User name Set the appropriate user name for connecting to the
modem when performing PPP authentication.
By default it should be left empty.
If a modem configuration file was downloaded, the
username variable overrides this setting.
Password Set the appropriate password for connecting to the
modem when performing PPP authentication.
By default it should be left empty.
If a modem configuration file was downloaded, the
password variable overrides this setting.
SNMP agent port Range: 0-65535
number Default: 161.
This number determines the UDP port number for setting
the SNMP context activate MIB variable in the radio.
Relevant only if Context activate radio is set to Enable in
the Advanced Link Layer.
SNMP trap port Range: 0-65535
number Default: 162.
This number determines the UDP port number for getting
traps from the radio via SNMP during context activation.
Relevant only if Context activate radio is set to Enable in
the Advanced Link Layer.
Packet data status Default: .1.3.6.1.4.1.161.3.6.30.2.1.1.1.
name This is a string identifying the MIB name for context
activating the radio. It is called packet data status (PDS)
MIB. Relevant only if Context activate radio is set to
Enable in the Advanced Link Layer.
Default routing IP The default gateway of the RTU.
address This value should remain 000.000.000.000.
IP network mask The subnet mask assigned by to the radio.
This value should remain 000.000.000.000.
76
10BMDLC over IP Communication
77
10BMDLC over IP Communication
78
10BMDLC over IP Communication
79
10BMDLC over IP Communication
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.
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.
80
10BMDLC over IP Communication
A modem configuration file such as XTL5000.stm for mobile XTL5000 radio can be
downloaded to override these defaults.
ATH – Disconnect the radio from PPP mode after issuing an abort sequence (+++).
81
10BMDLC over IP Communication
This connection is made using PPP and is basically the same as MDLC over Standard modem.
When the RTU is powered up, it sends a client string and expects a clientserver response. Only
when it gets that response will it initiate PPP and poll for CD. CD is constantly being polled,
and if it drops, PPP is disconnected. The user can opt to ignore CD using Advanced Link Layer
parameters in the site configuration. In this case, PPP is initiated upon power up. When
connected, CD is polled in order to stay connected. If it drops, then PPP is reconnected.
By default, the RTU acts as a Windows Null modem connection. It sends a client string and
expects a clientserver response before initiating PPP. The user can override this behavior by
downloading a modem configuration file.
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
82
10BMDLC over IP Communication
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.
[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> ; Wait 1 second.
<+++><><1> ; Wait 1 second.
84
10BMDLC over IP Communication
85
10BMDLC over IP Communication
86
10BMDLC over IP Communication
Modem restart
1. Prereset section.
2. Toggle RTS.
3. Postreset section.
This section is issued when first configuring the modem, or after failing to configure the
modem several times consecutively. The [Prereset] section is intended to restart power via an
AT command. If the modem does not support this feature, leave this section empty.
Depending upon the hardware setup with the modem, the RTU RS232 signals may be used to
power it off and on. For example with G18, the RTU toggle its RTS and powers off and on the
modem. A new board FCN6070 provides that feature for some portable radios such as ASTRO
IV&D XTS2500.
Finally, the RTU waits for the modem to power up, and then checks if it is alive by running the
[Postreset] section.
The RTU will not continue configuring modem until the modem restart succeeds. Leave those
sections empty if they are not supported by your modem.
Modem disconnection:
4. SetCommandMode section.
5. HangupPD section.
This puts the modem into command mode and makes sure the modem is connected to the port
prior to configuring it.
87
10BMDLC over IP Communication
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 modem’s DTR input, causing it to disconnect. For
that to work, the modem must have been configured previously with AT&D1.
Modem configuration:
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.
1. When it is detected that the modem is not PPP connected, or its DCD has dropped;
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,
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
88
10BMDLC over IP Communication
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.
MDLC over Dialup is different than MDLC over IP in the way it configures modem and
connects it. It is important to note that the same modem can work in both modes, but the user
must decide when configuring the port, what method to use. With MDLC over Dialup, the
modem is placed in circuit data mode, meaning it establishes phone call conversations with
remote sites upon transmitting to them. It accepts calls when another site transmits an MDLC
frame to it. Most of the time the modem is idle, meaning it is in command mode. It only
moves into data mode, when it needs to transmit or is called from another site. After a
predetermined idle time, the modem disconnects the call. With MDLC over IP, the modem is
ALWAYS in a “call”. The “call” is actually PPP mode. This enables it to receive MDLC over
IP frames from remote sites, as well as sending them. This “call” does not consume any air
resources since it begins with the RTU and ends in the modem itself.
MDLC over Dialup configures the modem by running the following sections of the modem
configuration file:
Modem disconnection:
1. SetCommandMode section.
2. HangupCD section.
This puts the modem into command mode and makes sure the modem is connected to the port
prior to configuring it.
Modem configuration:
4. ConfigureCD section.
Once the above is accomplished, the modem is not connected. It simply waits for calls, and if
frames need to be transmitted, the RTU initiates a call to a remote site.
To make it more reliable when using wireless modems such as G18 GSM modem in dial mode,
the modem is monitored periodically to check if it is registered. This is done by running the
chkvld section every few seconds. This section is optional, and if empty, no action is taken.
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.
89
10BMDLC over IP Communication
If you are using an external modem, set its configuration according to the following list.
Action Command
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.
RTU 2
MODEM AT
PORT SI2
MODEM AT
PORT SI1 MODEM AT
RTU 1 PSTN PORT SI2
RTU 3
MODEM AT
MODEM AT PORT SI2
PORT SI1 MODEM AT
MODEM AT
PORT SI2 PORT SI1
RTU 4 RTU 5
90
10BMDLC over IP Communication
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.
• Any transmission from RTU 1 to RTU 2 will cause automatic dialing. 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 1 to RTU 4 will cause automatic dialing to the
first number in the phone book. 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.
• 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.
91
10BMDLC over IP Communication
Note that for MDLC over Dialup, if a phone call is held, this operation is not executed and an
error is displayed. This means, that unlike MDLC over IP, diagnosing the modem using its
configuration file cannot be done remotely over dialup. (It can be done either locally from
another port or remotely from another link.)
The modem configuration file serves both types of ports: MDLC over IP port connected to a
packet data modem over PPP and MDLC over dialup port connected to a circuit data modem.
For MDLC over IP some of these variables also appear in the Site Configuration and are
marked accordingly. Some of these variables are relevant only for PPP (packet data), and some
are relevant for dialup as well.
The variables are initialized in the modem configuration file in the [Initialize] section
each time modem is to be configured. If a variable exists in the file, that value overrides default
settings in the site configuration.
• 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.
Usually a variable is set manually in the [initialize] section as explained above. For
example:
$WaitForOk= 2000
sets the WaitForOK variable to 2000.
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.
92
10BMDLC over IP Communication
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.
The following variables are used when programming the modem. Some of them are PPP-
specific. Some are common to both MDLC Over IP and MDLC Over Dialup.
93
10BMDLC over IP Communication
94
10BMDLC over IP Communication
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.
95
10BMDLC over IP Communication
96
10BMDLC over IP Communication
The following variable is for the [DiagX] section such as Diag0. It instructs the RTU to route
the modem response into the SW Diagnostics.
97
10BMDLC over IP Communication
If no <AT command> is specified, no command will be issued. Note that empty brackets <>
must be used if no command is to be issued.
If no <Expected response> is specified, the RTU will wait the specified timeout and ignore any
response. Note that empty brackets <> must be used if no response is expected. ‘0x0D’ should
be appended to the AT command with in this case.
If no <Timeout in seconds> is specified, the RTU will wait $WaitForOkTimeout seconds for
the modem to respond.
If the received response does not match the <Expected response>, the RTU will keep waiting
for specified timeout (500 milliseconds). If the desired response is still not received, it will
restart modem configuration again.
Each AT command response is automatically prefixed and appended with \n\r (0x0A and
0x0D) by the modem. When specifying the <Expected response>, there is no need to specify
them.
Multiple responses can be expected by specifying them inside the braces (of expected
response). For example:
<ATH><(OK)(NO CARRIER)>
will expect either OK or NO CARRIER response.
<AT+CREG?><+CREG:00(0)(1) 001>
will expect +CREG:000 0001 or +CREG:0001 001 as an output.
The \ delimiter can be used as an escape character if ‘$’ or ‘>’ is within an AT command or a
response, as follows:
<AT\$command><OK>
will issue AT$command and expect an OK response.
One can also send binary bytes instead of ASCII by prefixing each byte with ‘0x’ as follows:
<0x7e0xff0x030xc00x210x050x020x000x040x590x280x7e><><2> ; LCP
Terminate Request
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.
98
10BMDLC over IP Communication
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
In the example above, two sets of IP conversion tables should be created and the FEP’s Table
should be assigned to the RTUs:
FEPs Table:
99
10BMDLC over IP Communication
1 LINE1 192.5.1.161
1 LINE2 155.9.1.18
2 LINE1 192.5.1.162
2 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
The list above is sorted by ports – each port has its own DNS servers. The same DNS server
can appear in more than one port. Note: The www.mysite.com is the zone domain name
obtained from DHCP server.
In this example assume the operator has assigned two names for FEP: FEP1.moto.com for port
LINE1 and FEP2.moto.com for port LINE2. The FEPs Table should look as follows:
FEPs Table:
100
10BMDLC over IP Communication
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.
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.
1. Check that the radio/modem is powered up. This can generally be done by checking
the radio display. For Astro radios, the RTU powers it off and on every few seconds, if
it is unable to context activate it. If the radio has no display (e.g. Astro model type I),
check that the LED on top is turned on when the PTT button is pressed.
2. Check the connection status using the Software Diagnostics tool. In device LINxL,
level 101, verify that the State of configuration task is set to Connected and Registered.
(This means that the radio is context activated.) In device LINxL level 0, check that
the IP Address was set by the radio/modem/infrastructure (no longer 000.000.000.000).
Next, check that the Port is in Fail diagnostic is set to No.
3. If the above diagnostics indicate a configuration failure, repeat the steps described in
the MDLC over IP setup for the desired variation and check the physical connection
between the RTU and the radio. Certain Astro IV&D and GPRS radios/modems that
are not context activated will be restarted by the RTU. You can recheck the State of
Configuration Task and the Cause for configuration failure diagnostics and check the
error logger after two minutes. Verify that the Site ID appears in the IP Conversion
table, check the IP addresses, etc. For Astro IV&D radios that were configured using a
CPS, verify that the radio was programmed correctly.
4. Once the radio has been successfully context activated by the RTU, check the
communication over the air. For example, try to read the error logger from a remote
RTU using the STS. The local RTU should be able to communicate with the remote
RTU over the radio/modem.
5. If using host names, check with SW Diagnostics, device DNS_CLI level 1 that a DNS
server is OK. Each port may have its own set of DNS servers.
101
10BMDLC over IP Communication
102
Firewall
The ACE3600 Firewall package enables the user to define a variety of firewall protections.
The package is based on Windriver™’s 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.
Address List
The list of IP addresses allowed to pass through this firewall. If no IP address is defined, then
all address 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
• NTP port
103
Clock Functions and Synchronization
RTU Clock
The ACE3600 RTU has one time source, an internal system clock which is in microsecond
resolution. This time source is updated using a backup source of the RTC hardware
component - Real Time Clock (seconds accuracy).
In addition, external clocks, such as GPS and NTP servers can be used as a time source.
See NTP Clock Synchronization and Global Positioning System (GPS) below.
The time resolution of the system clock is hour, minute, second, millisecond, microsecond.
The date resolution is day, month, year. Leap year support is automatic.
When the RTU first starts up, the system clock is set according to the RTC, which always
retains its time in seconds (even when the RTU is powered down.) The RTU time can then
be set using a number of mechanisms.
The RTU clock controls the date and time of the ACE3600 unit. Date and time information
is used for timestamps on events such as time tagging changes to time tagged discrete
inputs, etc. Note these time tags are in millisecond resolution.
The ACE3600 includes configurable time zone support, where RTUs in one time zone can
adjust messages received from another time zone. The time zone is commonly used in
conjunction with NTP servers and a GPS receiver. These servers operate in UTC
(Universal Time Clock) which is in the (Greenwich Mean Time) GMT time zone. Setting
the time zone in a unit will adjust it to the local time.
The ACE3600 also supports daylight savings time. Daylight savings time is used only in
conjunction with a time zone. The start and end dates for daylight savings time (month,
day, hour) can be defined in the Daylight Saving Dates table. (The current year is
assumed.) The RTU will check these dates and adjust the time by one hour when
appropriate. The time zone is set in the STS site configuration and the daylight savings
time is set in the application system table.
In ACE3600 RTUs, a new MLDC extended time synchronization can be enabled which
includes the synchronizing RTU’s password. In this case, all RTUs in the system must use
the same password. This extended time synchronization also enables synchronizing two
104
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.)
• STS Date & Time utility – From the STS, the user sets the RTU date/time to the PC’s
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
105
monitoring a database table, see the Application Programmer chapter of the
ACE3600 STS User Guide.
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.
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.
106
Time Synchronization
The following Time Synchronization parameters are found in the Advanced tab of the STS
site configuration.
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.)
Check Password – RTU will check password in extended sync frames and
authenticate sync message 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. This is the default in ACE3600, but is relevant for
extended sync only.
Ignore Password – RTU will ignore password in extended sync frame and update the
clock for any extended sync frame. This is useful in case you
have RTUs with different passwords. RTUs with default
configuration have the default of Ignore Password.
What to do with received short sync messages? [Don’t Ignore SHORT sync messages]:
This parameter determines the behavior of the RTU when it receives a short (legacy) sync
frame. It has no meaning when receiving an extended MDLC sync. The valid values are:
Ignore SHORT sync messages – Do not update the clock when legacy sync
messages are received.
Don’t Ignore SHORT 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.
107
Time zone learning mode <No time zone/User Configured> [No time zone]:
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
determine daylight saving time. When receiving an extended time
sync from another RTU or when receiving Set Date & Time from
the STS, the difference in time zone is taken into account, so they
can operate in different time zones.
In this mode, daylight savings time start/end dates can be specified
in the Daylight Savings database table. When the unit moves from
no daylight savings to daylight savings, the time tag logger is
notified that the time has changed.
Note: If a user-configured RTU powers up when daylight savings time is in effect, and
errors occur during startup, those errors will be logged with no daylight savings time.
MonthStart: This variable represents the month (1..12) during which daylight savings
begins.
DayStart: This variable represents the day (1..31) on which daylight savings begins.
108
HourStart: This variable represents the hour (0..23) at which daylight savings begins.
MonthEnd: This variable represents the month (1..12) during which daylight savings ends.
DayEnd: This variable represents the day (1..31) on which daylight savings ends.
HourEnd: This variable represents the hour (0..23) at which daylight savings ends.
Use device NTP level 3 to view the local time with all its aspects, even when no NTP
servers are configured. This level will show the local time of RTU, if the unit is time zone
aware, the time zone in minutes (offset from GMT), and whether daylight savings time is in
effect.
In the MOSCAD system, the NTP works in client/server mode, in which a client RTU polls
another server and gets a reply. The server can be another RTU operating NTP, or a host
(PC, Unix, Linux). NTP poll the server RTU every 2 seconds, every 4 seconds, 8 and so on,
up to a poll every 17 minutes. NTP provides client accuracies typically within a
millisecond on LANs and up to 100 milliseconds on WANs (Internet, GPRS). Any RTU
(usually FEP) can act as a server. This enable setting its time via MDLC time sync, for
example, and having other RTUs specify it as an NTP server and obtain their time from it.
NTP synchronizes clock both in time and frequency. In time means it make its clock offset
as close as possible to the server. In frequency means it learns the server drift (time
between “ticks”) in order to avoid polling it every few seconds. An example, not related to
NTP, is ACE3600 send MDLC Sync over radio to another ACE3600. The clock offset
guaranteed to be less than 1 millisecond. However a 30ppm clock drift after 1 minute offset
will be 1.8 milliseconds. NTP prevents that by learning the drift frequency of the server.
User can set a single NTP server, or several ones. NTP operates under the assumption that
each server's time should be viewed with a certain amount of distrust. NTP really prefers to
have access to several sources of lower stratum time (at least three) since it can then apply
an agreement algorithm to detect insanity on the part of any one of these. Normally, when
all servers are in agreement, NTP will choose the best of these, where "best" is defined in
terms of lowest stratum, closest (in terms of network delay) and claimed precision, along
with several other considerations.
109
As the below figure shows, at the top of any NTP hierarchy are one or more stratum 0
reference clocks. These are electronic clocks such as GPS signals, radio signals, or
extremely accurate frequency control. Reference clocks are assumed to be accurate. In
ACE3600 a GPS port can be configured, it will serve as a reference clock for that RTU. In
this case RTU will operate on stratum 1 with an accuracy of 200 microseconds.
The accuracy of other clocks is judged according to how “close” a clock is to a reference
clock (the stratum of the clock, the network latency to the clock, and the claimed accuracy
of the clock. The accuracy of NTP thus depends on the network environment. Because NTP
uses UDP packets, traffic congestion could temporarily prevent synchronization, but the
client can still self-adjust, based on its historic drift. Under good conditions on a LAN
without too many routers or other sources of network delay, synchronization to within a
few milliseconds is normal. Anything that adds latency, such as hubs, switches, routers, or
network traffic, will reduce this accuracy. The synchronization accuracy on a WAN is
typically within the range of 10-100 ms. For the Internet/GPRS synchronization accuracy is
unpredictable, so special attention is needed when configuring a client to use public NTP
servers. Testing with the ACE3600 connected with the Internet gains accuracy of 20-30ms,
but theoretically it may be even 100ms.
NTP uses UTC time base (Coordinated Universal Time). UTC evolved from Greenwich
Mean Time (GMT). GMT is based on the earth’s rotation, which is not constant enough to
be used for detailed time measurements. UTC is based on a standard second length
determined by the quantum phenomena. There is a difference of a few seconds between the
two (14seconds in 2006), so every several years add one more second (called leap second)
to UTC. This is built in NTP protocol.
To translate the UTC time into local time, user can configure Time zones and Daylight
Savings in RTU. Note however, that if setting NTP server to another stand alone
ACE3600, which has no time zone, both will operate with the same local time if no time
110
zone set. If that ACE3600 is connected to a GPS or to another NTP server then there is a
need to set a time zone.
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:
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.
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.
The maximal interval in seconds between polling the NTP server(s). See ‘Minimal poll
interval in sec’ above. 1000 seconds is ~17 minutes.
111
Transmit BURST when poll <Yes/No> [Yes]:
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.
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.
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.
1. Check STS SW Diagnostic device NTP level 1. If it is operative, it will shows “clock
synchronized” and the current clock offset.
3. Check the application database system table Reserved flags field ClockValid. If it is 0,
this means NTP is not functioning properly.
Note: When NTP is OK (synced) the ClockValid flag is set to 1 in database system
Reserved flags table. In this case, the ACE3600 will inhibit any user attempt to
change the clock, either from the database monitor, STS Site Date & Time, or
when getting an MDLC Time Sync message. It could however, send an MDLC
Time Sync to other RTUs as initiated from a local connected STS, or from user
application.
1. Check STS SW Diagnostic device NTP level 2. It shows the list of NTP servers.
112
Sun Oct 29 10:33:07 2006 SITE: 2 LINK: LINE 2 DEVICE: NTP LEVEL: 2
Peer address port assoc Strat test Flags poll poll delay offset disper. maxrxtime
------------ ---- ----- ----- ---- ---- ---- ----- ------ ------- ------- ---------
10.5.1.160 ETH1 30780 16 0000H 0301H 617 409 0.000 0.000 0.000 0.000
*10.5.1.161 ETH1 30781 10 0000H 0341H 505 518 1.125 -0.729 0.071 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 ACE3600 RTUs use GPS timing receivers equipped with a 1 Pulse per Second (PPS)
output. The receivers are connected to an RTU port. In case of a satellite failure, the time
is manufactured internally and the receiver indicates its inability to trace the satellite.
The recommended GPS receiver is the Synergy Systems SynPaQ/E GPS Sensor with M12+
Timing Receiver which must be purchased from a Synergy vendor. Along with the timing
receiver, a data/power cable and antenna should be purchased. For details on connecting to
the GPS receiver, see Appendix A: RS232/RS485 Adaptor Cables in this manual.
113
RTU Site Configuration
Open the STS site configuration and configure any one of the serial or plug-in ports to
RS_232, Async, GPS receiver. Only ONE per RTU can be configured as GPS receiver.
The other parameters are automatically set as shown below.
The default parameters values are set for the Oncore M12+T receiver, but may be changed,
as necessary.
The GPS advanced parameters explained in ACE3600 STS User Guide, Appendix A Site
configuration parameters. The most important parameters are shown below:
Range: 0- 86400000
Range: Disable/Enable
114
Set GPS in position Hold (Timing only) Default: Enable
Range: Disable/Enable
Range: Yes/No.
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.
115
The ladder controlled GpsOfs value is included in the Reserved Values (system) table.
This value enables the user to update the MOSCAD unit to Daylight Savings Time.
The GpsOfs default value is ‘0’, and it may be either positive or negative according to the
specific time changes (measured in hours). This value is added to the local offset from
universal time ‘Offset in milliseconds’ value, defined in the port Advanced Properties
window.
When the GpsOfs is set, the RTU time is updated starting from the next GPS report, except
following a “cold restart”, which may last up to one minute.
Verify the GPS time using STS SW Diagnostics, device GPS level 1. or using device NTP
level 1 to see that time is synchronized, and level 3 to see the local time.
116
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.
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.
117
Core Dump
118
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).
119
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.
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:
120
Protocol Analyzer
RTU
FIU
FIU
CENTRAL
RTU
PROTOCOL ANALYZER
PORT
PI1
PORT
SI1
PORT
SI2
PORT RADIO
STS PI2
CPU MODULE
To monitor the communication on a multi-drop link, connect Port PI2 through a 2-wire
multi-drop adaptor to the channel – see the figure below. Port PI2 should be defined
according to the type of modem and the data speed in use.
RTU RTU
RTU RTU
RTU
2-WIRE MULTI-DROP
CENTRAL
PROTOCOL ANALYZER
PORT
PI1
PORT
SI1
PORT
SI2
PORT 2-WIRE
PI2 MULTI-DROP
STS ADAPTER
CPU MODULE
121
Protocol Analyzer
FULL-DUPLEX TO
ACE3600 MDLC PROTOCOL
COMPUTER
RTU OR
MONITORED ACE3600 SITE
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 Adaptor for RTU Rx Monitoring
122
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.
123
Protocol Analyzer
124
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.
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.
MDLC Frames The data being monitored should be collected in the log file in a
format which will enable MDLC based analysis. If MDLC
Frames is selected, analyzed data can be viewed as in Analyzing a
Log File below.
Free Format The data being monitored should be collected in the log file in a
format which will not enable MDLC based analysis. The log file
will show the raw data going over the link. Non-MDLC analysis,
where the data is divided into frames based on delimiters specified
by the user, can be performed on the log file. See the Non-MDLC
Frame Delimiters field in the Set MDLC Layers to Analyze dialog.
7. Once the parameters are set, you are ready to start monitoring.
2. To temporarily stop the monitoring of the link, select the Pause Monitoring
command from the Monitor menu, or click on the Pause Monitoring icon.
3. To stop the monitoring of the link, select the Stop Monitoring command from the
Monitor menu, or click on the Stop Monitoring icon.
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.
125
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).
2. Select the log file from the drop-down list and click OK to open it.
The analyzed file lists all the monitoring options which were selected under
Analyze Log file (which MDLC layers were monitored, source/destination address
ranges) and the actual analyzed data. This data is displayed by layer with each
frame described in detail (date sent, sending site, frame content) as shown below.
Because all seven layers of the MDLC protocol were selected to be analyzed (using the
Analyze Log File command) the 18 bytes which were sent over the link are shown (seven
in the Link layer, one in the Network layer, etc.) If not all the layers were analyzed, the
number of bytes displayed would be less than 18.
Note that the designation of the site (Site I/Site II) is used to differentiate between the two
transmitting sites, but the actual Destination and Source Site IDs are shown in the data
frame content. When monitoring a multi-drop link (remote), all logged monitored data will
seem to originate from Site I. When monitoring an RS232 link, the data will either be
marked Site I (first to transmit) or Site II (second to transmit).
126
Protocol Analyzer
127
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.
128
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.
129
PID LOOP - Proportional Integral
Derivative
General
The following figure describes the PID Loop performed by the ACE3600 RTU.
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:
dt
where:
130
PID LOOP - Proportional Integral Derivative
IN(t) - the PID input that represents the measured process value in "Input
Engineering Units" [IEU].
OUT(t) - the output of the PID loop in "Output Engineering Units" [OEU].
In the PID table, all the abovementioned variables have the prefix pid, i.e. IN becomes
pidIN, SP becomes pidSP, etc.
PID Function
The PID function performs the following three calculations:
• 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.
131
PID LOOP - Proportional Integral Derivative
• 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 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.
132
PID LOOP - Proportional Integral Derivative
• 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
This real parameter value starts with an initial value which represents I0. It is
continuously modified to represent the value of the above equation. The value may be
changed in the rungs to any desired value.
• 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.
The example below shows a PID application for an ACE3600 RTU. While the specific
application controls water flow, the concept of the PID control is universal and the example
described herein can be used for other applications.
133
PID LOOP - Proportional Integral Derivative
General
This application is used to control water flow by changing the position of a regulating
valve. The flow is measured by an Analog Input (range: 0-15000 liter/hour). The valve
position is controlled by an Analog Output (range: 0-100%).
The database used in this example is described below. Each table in the database is shown
as it appears in the application. Each variable used in the tables is described. Finally the
application process rungs are described as they have been implemented in the sample
project.
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
1. The proportional part of the PID function contributes to its output the result of
(PidK) * (Err). That means that AO increases when Err increases, and AO decreases when
Err decreases, by the proportional gain PidK.
The PID function does not put a limit to the proportional part. In certain cases, when Err is
large, it may cause the AO to be changed by large steps and to reach its limits. This may
cause fluctuations in analog output and unstable condition of the controlled process. In
order to prevent this problem, the application reduces the PidK when Err is large. Thus the
Integral action is dominant when Err is large, and the Proportional action is more dominant
when Err is small.
134
PID LOOP - Proportional Integral Derivative
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.
135
PID LOOP - Proportional Integral Derivative
0 0
PID Table
Table name: PID Table COS name:
Table symbol: Last index (Ind): 0
Last index name: I_PID
0 0% 0.0 1.0
0 0% 0.0 1.0
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.
136
PID LOOP - Proportional Integral Derivative
pidK - Proportional gain factor. A default value is defined in the table. Application changes
the value according to Err value, as explained later.
pidKd - Differential factor. Equals zero. Not used for flow control process.
pidKi - Integral factor. A default value for the integral part mutiplier is defined in the table.
However, application changes this value when the relevant pidK is changed, as explained
later
pidInt - Accumulated (calculated) integral part.
pidDb - PID Process output deadband sets the minimum step of change in the PID function
output. In the application example it is set to zero. For fast response process this value
should be kept to a minimum.
pidOUT - PID function output. This value is not linked directly to the analog output. The
scaling of the output can be defined in this column, by setting the EGU Zero and EGU
High accordingly. For the process in this example the output range is defined as 0 - 100
(%). Its value is checked to be in a certain range before updating the analog output variable.
137
PID LOOP - Proportional Integral Derivative
EGU High –used to define the scaling of the PID controlled value input pidIN
0 3.0-4 10.0
138
PID LOOP - Proportional Integral Derivative
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)
0 TPID 01:00
TPID - PID calculation time interval (multiplied by 10 ms). The timer preset value is set by
PtPID.
0 BTemp
139
PID LOOP - Proportional Integral Derivative
0 PtPID 100
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:
Rung Description
P05 Scan PID AI
P10 Reset Index p
PL10 Local Setpoints
PL12 Local Setpoints
P18 Manual mode limits
P20 Manual Mode
P21 Jmp P50 if no TPID
P25 Auto Mode
P30 Check Input range
P50 Increment Index p
P60 Check Index p
P90 Run PID Calc
M91 Jmp P200 if no TPID
P100 Reset Index p
P110 Check Output range
P112 Calc PID loop error
P113 Set PI factors
140
PID LOOP - Proportional Integral Derivative
Rung P05: Scan the analog input (CV) of the PID loop.
Pid_AI
P05 (SCAN)
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
P10 ( RST )
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.
ModSet,p AO_Set,p
PL12 = (MOVE)
Auto Pid_AO,p
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.
AO_Set,p Pid_AO,p
< (MOVE)
AO_Min 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.
141
PID LOOP - Proportional Integral Derivative
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.
Pid_AI,p Pid_AI,p
= =
CV_Min,p CV_Max,p CV_Set,p
(MOVE)
pidSP,p
AO_Set,p AO_Set,p Pid_AO,p
> < (MOVE)
AO_Min AO_Max AO_Set,p
AO_Set,p AO_Set,p
= =
AO_Min AO_Max pidInt,p
(MOVE)
Pid_AO,p
Rung P21: Skips the next two rungs when PID loop is not calculated.
TPID P50
P21 / ( 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.
CV_Set,p CV_Set,p
= =
CV_Min,p CV_Max,p AO_Set,p
(MOVE)
Pid_AO,p
142
PID LOOP - Proportional Integral Derivative
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.
Pid_AI,p Pid_AI,p
= =
CV_Min,p CV_Max,p
Pid_AI,p pidIN,p
> (MOVE)
CV_Max,p CV_Max,p
Pid_AI,p pidIN,p
< (MOVE)
CV_Min,p CV_Min,p
Rung P50: Counts up (increments) the index counter (to execute the next loop).
p
P50 ( CTU )
p PL10
P60 < (JMP)
I_PID
p
=
I_PID
Rung P90: Runs the PID calculation on all loops every TPID interval.
TPID P.I.D.
P90 ( CALL )
Rung M91: Skips the next rungs, which check the PID function results, if PID function was
not performed.
TPID P200
M91 / ( JMP )
143
PID LOOP - Proportional Integral Derivative
p
P100 ( RST )
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.
pidOUT,p Pid_AO,p
> (MOVE)
AO_Max,p AO_Max,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.
ModSet,p PidDif,p
P112 = - pidSP,p
Auto Pid_AI,p
DifTmp,p
(MOVE)
PidDif,p
DifTmp,p DifTmp,p
< - R0
R0 DifTmp,p
RTemp,p
(CALC)
RTemp,p
AlrTim,p
>
(DON)
AlrDB,p
AlrTim,p PidAlr,p
( )
144
PID LOOP - Proportional Integral Derivative
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.
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.
145
PID LOOP - Proportional Integral Derivative
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.
Rung P130: Counts up (increments) the index counter (to execute the next loop).
p
P130 ( CTU )
Rung P200: Writes the resulting analog output to Pid_AO by Scan operation.
Pid_AO
P200 ( SCAN )
TPID TPID
P210 (MOVE)
PtPID
TPID TPID
/ (DON)
146
Enhanced PID
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 to the STS.
For more information, see the ACE3600 Enhanced PID Application User Guide, provided
with the RTU.
147
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 IRRInet-
M System Planner.
The STS does not support legacy Irrigation units: IRRIcom, IRRInet-XL or IRRInet-XM.
However, the STS can be used with certain legacy units, as described in Legacy Irrigation
RTUs below.
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.
• 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 Piccolo-
XR 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.
148
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.
With PIU connectivity, the IRRInet-M can activate Piccolo-XR units.
The IRRInet-M RTU can be programmed on site, using an IRRinet Terminal for Pocket
PC.
The IRRInet-M (master mode) may be installed in a totally new irrigation system, ICC V14
or higher. The IRRInet-M (slave mode) may be installed in a legacy system in addition
to/instead of a legacy Scorpio unit.
Important: Although the IRRInet-M looks like the IRRIcom and MOSCAD-M on the
outside, it is a different unit, with different connectors, hardware, and software. These
units are NOT interchangeable.
• 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)
• Real-time monitoring of application tables in the RTU
• Downloading/uploading files
• Updating the RTU date and time
• Testing hardware elements and plug-in communication ports
• Retrieving errors and software diagnostics logged in the RTUs
For detailed information on using the STS to configure and deploy units, see the ACE3600
STS User Guide.
149
Irrigation
Note: When an IRRInet_M is connected to a PIU (via RS232), the port’s advanced physical
parameter ‘RTS Always On’ must be set to Yes.
STS Radio1
PIU
PC RSlink1
Radio
RTU 2
RTU 102 (Intrac) Scorpio
RSlink19
RSlink2
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
150
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 GUI’s 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.
As with legacy MOSCAD RTUs, the site configuration of legacy irrigation units must be
imported. See the instructions on importing a site configuration in the Operation chapter of
the ACE3600 STS User Guide.
The table below lists the Add-on files which should be imported from the Toolbox project
directories [C|D]:\Tbox954\... and downloaded together with the site configuration and
network configuration to the units. See the instructions on using Add-on files and
downloading in the Operation chapter of the ACE3600 STS User Guide.
151
Irrigation
Important: Because the irrigation system works with ICC V14, all legacy irrigation RTUs
must be upgraded to V570 of the project files.
152