ACE3600 STS Advanced Features

Advanced Features sm

ACE3600 System Tools Suite (STS) Version 0 17.60

6802979C15-M

MOTOROLA, MOTO, MOTOROLA SOLUTIONS and the Stylized M Logo are trademarks or registered trademarks of Motorola Trademark Holdings, LLC and are used under license. All other product or service names are the property of their respective owners. Copyright © 2013 All rights reserved

AB

COMPUTER SOFTWARE COPYRIGHTS 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. This media, software or hardware ("Product") obtained from Motorola Solutions, Inc. ("Motorola Solutions") may include Motorola Solutions’ Software, Third Party Software (defined below), and/or Open Source Software (defined below). The object code or source code (collectively, the "Software") included with the Product is the exclusive property of Motorola Solutions or its licensors, and any use is subject to the terms and conditions of one or more agreements in force between the purchaser of the Motorola Solutions Product or licensee of the Motorola Solutions Software and Motorola Solutions. SOFTWARE IS PROTECTED BY U.S. COPYRIGHT LAWS AND INTERNATIONAL LAWS AND TREATIES. UNAUTHORIZED COPYING, DISTRIBUTION OR OTHER USE OF THIS PRODUCT IS STRICTLY PROHIBITED. ANY DISTRIBUTION OR USE NOT SPECIFICALLY APPROVED BY MOTOROLA SOLUTIONS IS STRICTLY PROHIBITED. Motorola Solutions’ Software is subject to the commercial terms and conditions entered into with Motorola Solutions, any other use is strictly prohibited. Commercial Software licensed for redistribution by Motorola Solutions ("Third Party Software") is subject to the terms and conditions in force between Motorola Solutions and the licensor of the Third party Software. The terms and conditions governing the usage of Third Party Software may be part of the agreement entered into by the purchaser of the Product with Motorola Solutions or separate Third Party Software license agreement(s) included with the Product. Software provided by Motorola Solutions which is covered by a publicly available license governed solely under Copyright law, whereas the complete terms and obligations of such license attach to a licensee solely through the act of copying, using and/or distribution of the licensed Software, such obligations often include one or more of attribution obligations, distribution obligations, copyleft obligations, and intellectual property encumbrances is referred to herein as "Open Source Software". The use of any Open Source Software is subject to the licenses, terms and conditions of the commercial agreement in force between the purchaser of the Product and Motorola Solutions as well as the terms and conditions of the corresponding license of each Open Source Software package. If there is a conflict between the terms and conditions of any commercial agreement and the terms and conditions of the Open Source Software license, the applicable Open Source Software license will take precedence. Copies of the licenses for the included Open Source Software as well as their attributions, acknowledgements, and software information details, are listed below. Motorola Solutions is required to reproduce the software licenses, acknowledgments and copyright notices as provided by the authors and owners, thus, all such information is provided in its native language form, without modification or translation. For instructions on how to obtain a copy of any source code made publicly available by Motorola Solutions related to Open Source Software distributed by Motorola Solutions, you may send your request in writing to: Motorola Solutions, Inc. Open Source Software Management 1301 E. Algonquin Road Schaumburg, IL 60196 USA. In your request, please include the Motorola Solutions Product name and version, along with the Open Source Software specifics, such as the Open Source Software name and version. Note: the source code for the Open Source Software included by Motorola Solutions may be resident on the Product’s installation media provided with the Product or on supplemental Product media. Please reference and review the entire Motorola Solutions Open Source Software “Legal Notices” and any corresponding “End User License Agreement” provided with the Product or the commercial agreement under which the Product was purchased for details on the availability, location and method for obtaining source code. Further, depending on the license terms of the specific Open Source Software, source code may not be provided. Please reference and review the entire Motorola Solutions Open Source Software “Legal Notices” and “End User License Agreement” to identify which Open Source Software packages have source code provided or available. To view information regarding licenses, acknowledgments and required copyright notices for Open Source Software used in this Product, please select “Legal Notices” from the graphical user interface of the Software (if applicable) or as specified in the “Legal Notices” or End User License Agreement File/README associated with the Product. Use of any Software is subject to acceptance of the corresponding terms associated with the Software and by using the Software you agree you have reviewed the terms and agreed to be bound by said terms.

MOTOROLA, MOTOROLA SOLUTIONS and the Stylized M Logo are trademarks or registered trademarks of Motorola Trademark Holdings, LLC and are used under license. All other trademarks are the property of Motorola Solutions, Inc. or their respective owners. All rights reserved.

Motorola Solutions, Inc. 1301 E. Algonquin Road, Schaumburg, IL 60196 U.S.A.

Table of Contents TABLE OF CONTENTS .......................................................................................................................................... I SCOPE ................................................................................................................................................................ 1 ACE3600 I/OS ................................................................................................................................................... 2 I/O Configuration ......................................................................................................................................... 2 I/Os and the Application ............................................................................................................................... 3 I/Os Hot Swap ............................................................................................................................................... 3 I/O Module States ......................................................................................................................................... 3 Sleep Mode.................................................................................................................................................... 4 Hardware Tests ............................................................................................................................................. 4 Freeze Mode ................................................................................................................................................. 4 Select Before Operate DOs ........................................................................................................................... 5 I/O Expansion ............................................................................................................................................... 8 I/O Expansion Frames in the ACE3600 Database ....................................................................................... 8 I/O Expansion Configuration........................................................................................................................ 8 Time & Sequencing Synchronization of I/O Expansion ................................................................................ 9 AUTOMATIC I/O RECOGNITION ........................................................................................................................ 10 POWER MANAGEMENT ..................................................................................................................................... 12 Configuration .............................................................................................................................................. 12 Constraints .................................................................................................................................................. 13 SAFE FIRMWARE DOWNLOAD .......................................................................................................................... 14 FLASH FILE SYSTEM ......................................................................................................................................... 15 General ....................................................................................................................................................... 15 User Generated Flash Files ........................................................................................................................ 16 Accessing Flash Files ................................................................................................................................. 16 Writing Flash Files ..................................................................................................................................... 17 Logging Flash Files .................................................................................................................................... 17 Flash File Headers ..................................................................................................................................... 17 Flash Files Diagnostics .............................................................................................................................. 18 DATABASE BACKUP ......................................................................................................................................... 19 Database Backup Operations ..................................................................................................................... 19 Database Backup Site Configuration.......................................................................................................... 20 BlocksToBackup Table ............................................................................................................................... 21 Database Backup Diagnostics .................................................................................................................... 22 ACCESSING DATABASE VARIABLES VIA COORDINATES.................................................................................... 24 Definitions................................................................................................................................................... 25 EVENT DRIVEN SOFTWARE .............................................................................................................................. 27 Definitions................................................................................................................................................... 27 Event Driven Mechanism ............................................................................................................................ 28 Event Driven Tables.................................................................................................................................... 29 How to Use the Event Driven Software....................................................................................................... 30 FAST EVENTS ................................................................................................................................................... 36 Events Triggers ........................................................................................................................................... 36 Fast Event Definition and Configuration.................................................................................................... 36 Fast Event Scheduling ................................................................................................................................ 37 Enabling/Disabling Fast Events ................................................................................................................. 37 Monitoring of Fast Events .......................................................................................................................... 38 i

Table of Contents

Fast Events Diagnostics .............................................................................................................................. 38 Testing Fast Events ..................................................................................................................................... 38 Fast Events and Automatic Recognition ..................................................................................................... 39 RTU AND POWER SUPPLY REDUNDANCY ........................................................................................................ 41 Redundant RTU Site Configuration ............................................................................................................ 42 Redundant RTU User Application .............................................................................................................. 43 Redundant RTU Communication ................................................................................................................ 44 Downloading to/Uploading From Redundant Sites .................................................................................... 45 Hardware Tests of Redundant Sites ............................................................................................................ 45 Changes to Redundant RTUs ...................................................................................................................... 45 NETWORK CONFIGURATION ............................................................................................................................. 47 Routing of Data Frames ............................................................................................................................. 47 Routing over Alternative Direct Link .......................................................................................................... 48 Routing using Remote Failed Links Table .................................................................................................. 49 Using the Time To Live Counter ................................................................................................................. 50 Routing using Alternative Path to Local Link ............................................................................................. 50 MDLC OVER IP COMMUNICATION................................................................................................................... 52 Overview ..................................................................................................................................................... 52 Broadcast and Setcalls................................................................................................................................ 53 New Features for MDLC over IP in ACE3600 ........................................................................................... 53 MDLC over IP/PPP Connections ............................................................................................................... 56 MDLC over IP/LAN Connections ............................................................................................................... 56 MDLC over IP/Remote NDIS Host Connection .......................................................................................... 57 STS PC Communication Setup Options ...................................................................................................... 57 MDLC over IP Setup ................................................................................................................................... 58 MDLC over IP Site Paging ......................................................................................................................... 58 MDLC over LAN/Ethernet .......................................................................................................................... 59 MDLC over iDEN ....................................................................................................................................... 65 MDLC over Tetra ........................................................................................................................................ 78 MDLC over Standard Modem ..................................................................................................................... 86 MDLC over GPRS....................................................................................................................................... 89 MDLC over ASTRO IV&D .......................................................................................................................... 91 MDLC over MotoTrbo .............................................................................................................................. 100 MDLC over Null Modem........................................................................................................................... 102 Modem Configuration File ....................................................................................................................... 102 IP Conversion Tables................................................................................................................................ 119 MDLC over IP Connection Verification ................................................................................................... 121 FIREWALL ...................................................................................................................................................... 122 Firewall Configuration ............................................................................................................................. 122 Firewall with I/O Expansion ..................................................................................................................... 123 CLOCK FUNCTIONS AND SYNCHRONIZATION .................................................................................................. 126 RTU Clock................................................................................................................................................. 126 Time Adjustment and Synchronization...................................................................................................... 126 Time Parameter Configuration ................................................................................................................. 128 Time Synchronization Diagnostics............................................................................................................ 132 NTP Clock Synchronization ...................................................................................................................... 132 Global Positioning System (GPS) ............................................................................................................. 136 Clock Synchronization of I/O Expansion Frames ..................................................................................... 139 ACE IP GATEWAY ......................................................................................................................................... 140 ACE IP Gateway System Overview ........................................................................................................... 141 ii

Table of Contents

Health Check Mechanism ......................................................................................................................... 145 ACE IP Gateway Site Configuration ........................................................................................................ 148 ACE IP Gateway Terminal Server Ports .................................................................................................. 149 ACE IP Gateway Redundancy .................................................................................................................. 150 MDLC PASSWORD CHANGE .......................................................................................................................... 153 CORE DUMP ................................................................................................................................................... 155 MDLC ENCRYPTION ...................................................................................................................................... 156 PROTOCOL ANALYZER ................................................................................................................................... 157 PID LOOP - PROPORTIONAL INTEGRAL DERIVATIVE..................................................................................... 167 General ..................................................................................................................................................... 167 PID Function ............................................................................................................................................ 168 PID Table.................................................................................................................................................. 168 How to Use the PID .................................................................................................................................. 170 PID Application Example ......................................................................................................................... 171 ENHANCED PID ............................................................................................................................................. 184 IRRIGATION .................................................................................................................................................... 185 Irrigation Unit Types ................................................................................................................................ 185 STS Functions for Irrigation Units ........................................................................................................... 186 Tips on Using the STS for Irrigation ......................................................................................................... 187 APPENDIX A: ACCESSORIES, ADAPTORS AND CABLES ................................................................................. A-1 Connection to a Computer or Terminal ..................................................................................................... A-1 Connection to a Modem ............................................................................................................................. A-2 Connection to GPS Receiver ...................................................................................................................... A-3 Connecting a User Port to a Printer .......................................................................................................... A-4 Connecting a User Port to an External Unit ............................................................................................. A-4 Connection to a Radio ............................................................................................................................... A-4 RTU-to-RTU Connection Using MDLC Protocol through RS232 ............................................................. A-6 RTU-to-RTU Synchronous Communication Using Plug-in Port ............................................................... A-6 ACE3600 RTU-to-ACE3600 RTU Connection Using MDLC Protocol through RS485 ............................ A-7 ACE3600 RTU-to-MOSCAD RTU Connection Using MDLC Protocol through RS485 ........................... A-7 ACE3600 RTU-to-PC Ethernet Port Direct Connection without Hub....................................................... A-8 ACE3600 RTU Main CPU to Expansion Module Direct Connection........................................................ A-8 ACE3600 RTU Main CPU to Expansion Module Connection via LAN Switch ......................................... A-9

APPENDIX B: REMOTE STS MODEM SETUP ................................................................................................. B-1 Hayes ACCURA 144 + FAX 144, V2.20E ................................................................................................. B-1 Hayes ACCURA 144 + FAX 144, V4.1...................................................................................................... B-4 Motorola OnlineSURFR 28.8 .................................................................................................................... B-5 Motorola OnlineSURFR 33.6 .................................................................................................................... B-8 Motorola OnlineSURFR 56K ..................................................................................................................... B-9 UDS V.3225 ............................................................................................................................................. B-10 UDS V.3400 ............................................................................................................................................. B-12 USRobotics Sportster 14400 Fax ............................................................................................................. B-14 USRobotics Sportster 28800 Fax ............................................................................................................. B-17 USRobotics Sportster 56K Fax ................................................................................................................ B-20 Intel SatisFAXtion Modem/400e .............................................................................................................. B-21 Multitech Leased Line Modem ................................................................................................................. B-24

iii

Table of Contents

APPENDIX C: PC COMMUNICATION OVER MOTOTRBO ................................................................................... C-1 Installing the USB Driver (Windows XP) for the radio: ............................................................................ C-1 Programming the Radio............................................................................................................................. C-2 Communicating over the Air via MotoTrbo Radio: ................................................................................... C-2

iv

Scope This reference manual provides useful background information on ACE3600 advanced system features, communication features, and specialized utilities and features. The system features include: •

ACE3600 I/Os

•

Automatic I/O Recognition

•

Power Management

•

Safe Firmware Download

•

Flash File System

•

Database Backup

•

Accessing Database Variables via Coordinates

•

Event Driven Software

•

Fast Events

•

RTU and Power Supply Redundancy

The communication features include: •

Network Configuration

•

MDLC over IP Communication (Static LAN, Dynamic – DHCP Client, or PPP)

•

Firewall

•

Clock Functions and Synchronization

•

ACE IP Gateway

•

MDLC Password Change

The utilities include: •

Core Dump Logger

•

MDLC Encryption

•

Protocol Analyzer

•

PID LOOP - Proportional Integral Derivative

•

Enhanced PID

•

Irrigation

•

Project Synchronizer

1

ACE3600 I/Os I/O Configuration The basic ACE3600 RTU can include up to eight I/O modules in any combination, arranged in a single frame and numbered 1-8. Optionally, I/O expansion frames can be added to the ACE3600 RTU, increasing the number of I/O modules controlled by the CPU module on the main frame. I/O expansion is based an expansion LAN switch installed on the main frame, and an expansion module plus a power supply installed on the I/O expansion frame. Up to 110 I/Os can be connected to the ACE3600, by using two expansion LAN switches on the main frame and thirteen I/O expansion frames. For details on setting up a system with I/O expansion, see the ACE3600 RTU Owner’s Manual. The RTU’s I/O modules are configured in the ACE3600 STS I/O tab during site configuration (see figure below.) The module types are selected from a drop-down list and include an FLN number which is also printed on a label on the left side of the physical module. Two different DI/DO FET modules (FLN3553, FLN3554) are available, with up to 16/32 user connections which can be configured as either DI or DO, in groups of eight. For a list of the available I/O modules, see the ACE3600 STS User Guide or the ACE3600 RTU Owner’s manual.

The I/O tab includes a field, ‘Enable auto I/O modules recognition at startup,’ which instructs the unit to automatically recognize I/O modules when it is started up. This saves the user time when configuring the site in the STS. If automatic recognition is enabled, no I/O modules can be defined for the site and the I/O configuration must be uploaded from a unit. For more information, see Automatic I/O Recognition below. Settings for I/O modules and individual I/Os can be set using the Advanced Configuration of the specific I/O module. This includes defining values such as DO power source, AI/DI filters, 2

ACE3600 I/Os

and AI differential. For details, see the Customizing the Configuration of a Site section of the ACE3600 STS User Guide.

I/Os and the Application The I/Os controlled by the RTU are represented by variables in the application database tables and manipulated by the application process rungs. The process of linking the database variables to the physical I/Os of the site is performed before compiling the application in the Application Programmer. For more information, see Linking I/Os to the Database in 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.

I/Os Hot Swap The ACE3600 RTU has a hot swap capability, which means that an I/O module can be removed from its slots and reinserted (or replaced by another module of the same type) without powering down the unit. The only exception to this rule is the main power supply module, which cannot be removed during normal operation. 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).

I/O Module States An I/O module can be in one of three states in the unit: •

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.) 3

ACE3600 I/Os

Sleep Mode Each I/O module can be switched by the user application program to Sleep Mode. In Sleep Mode, the module does not function and the power consumption is minimized. During Sleep mode, the user application program will get the predefined values (PDV) or keep the last value (KLV) for each I/O. The PDV/KLV values are set in the I/O link table of the application program. For more information, see the Application Programmer chapter of the ACE3600 STS User Guide.

Hardware Tests The 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: •

when the Hardware Test utility is closed,

•

after ten minutes have elapsed,

•

when the stopped application is run or the frozen module is unfrozen.

For more information, see the ACE3600 STS User Guide.

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

ACE3600 I/Os

Select Before Operate DOs As of firmware v14.00, the ACE3600 RTU supports Select Before Operate digital output (DO) relays for safe output activation in secure operations. The SBO feature is used to ensure that the correct output has been selected before actually activating the relay. The table below compares the activation of SBO relays to that of standard DO relays. DO Relay Steps

SBO DO Relay Steps

Selected relay is activated. (Scan out DO.)

Relay is selected.

Back indication (BI) is checked. (Scan in BIs of the module.)

Select back indication (SBI) is checked. (Scan in SBIs of the module.) Relay is activated (either for a specific duration or forever) Back indication (BI) is checked. (Scan in BIs of the module.) Reset SBO.

The SBO feature can be implemented in the user ‘C’ or ladder application. The application can perform each SBO operation separately (select, check, operate) or have the system perform the select, check and operate automatically. The user specifies the duration of the relay operation (or forever) as a parameter. IMPORTANT: Unlike standard DOs (where several DOs can be activated at once), only one SBO DO per RTU can be activated at a time. However, a single Scan In of the ‘Select’ Back Indication and ‘Activate’ Back Indication can be done at once for all DOs in a specified module.

Site Configuration for SBO Relays The following I/O parameter is configured for the RTU in the Advanced tab of the STS site configuration. SBO relay check hardware timeout <0-65535> msec

[50]:

Time to wait for the hardware Check. After this timeout, a hardware failure message is sent. (Internal use only). SBO relay select timeout

[5000]:

This parameter determines how much time may elapse between the Select and the Operate. After this timeout, the SBO DO will be reset (the Select is aborted.) This parameter is only relevant when the user calls Select, Check, and Operate separately. When the system performs the SBO automatically, this parameter is not checked.

5

ACE3600 I/Os

SBO DOs in User Ladder Applications The SBO functionality can be programmed in a user ladder application. The following four functions can be called using the CAL operator. (The function name is the first parameter of the CAL operation.) Function Name

Description

SBO

Performs Select, Check and Operate on the specified SBO automatically.

SBO_select

Performs Select of the specified SBO. After calling this function, the user program should check the SBI back indication.

SBO_operate

Performs Operate of the specified SBO. This function is called after the check indicates that the desired SBO DO relay was selected. The duration of the operation is determined in the SBOduration Reserved Value.

SBO_reset

Resets the current operation and selection. All SBO DOs are unselected.

The specified SBO is a discrete output (d-o) type which is I/O linked to SBO_1 – SBO_X in a specific module. To link the output: 1. In the ladder database, generate a (d-o) column in a single or multi column table. 2. Link the specified I/O (rack and module) to SBO_X using the drop-down list. 3. Pass the linked cell to the CAL operator as the second parameter. (You can use a dynamic index.) In order to check the select back indication(s) SBI after selecting a DO, you must do as follows: 1.

In the ladder database, generate a (d-i) column in a single or multi column table.

2.

Link the I/Os (rack and module) to SBI_1 – SBI_X using the drop-down list.

3.

Scan in the column.

In order to check the back indication(s) BI after operating a DO, you must do as follows: 1.

In the ladder database, generate a (d-i) column in a single or multi column table.

2.

Link the I/Os (rack and module) to BI_1 – BI_X using the drop-down list.

3.

Scan in the column.

For details on the CAL operator, see Appendix B: Ladder Diagram Language of the ACE3600 STS User Guide. For details on programming ladder applications, see the Application Programmer section of the ACE3600 STS User Guide.

SBO Reserved Values Three indicators in the Reserved values system table can be used by the ladder application to check the SBO status and associated errors. These are as follows:

6

ACE3600 I/Os

SBOduration - This value can be used to set the operation duration (in units of 1 msec). (Infinite = -1). SBOstatus - This value indicates the status of the SBO process (i.e. if the SBO was selected or operated already). In this way, the application can know whether to check back indications or whether another SBO operation can be generated. SBOerror - This value is indicates the type of error from the last SBO step. For details on these three values, see Appendix C: Database Tables and Data Types of the ACE3600 STS User Guide.

SBO DOs in User ‘C’ Applications The SBO process can be programmed in a user ‘C’ application using the following functions: MOSCAD_SBO (rack_module, SBO, duration) - Performs Select, Check, and Operate on the specified SBO DO in the specified I/O module for the specified duration. MOSCAD_SBO_select (rack_module, SBO) - Performs Select of the specified SBO DO in the specified I/O module. MOSCAD_rm_SBO_check (rack_module, p_check_bits) - Performs Check of the specified I/O module and returns the check bits status for the module. MOSCAD_SBO_operate (rack_module, SBO, duration) - Performs Operate on the specified SBO DO in the specified I/O module for the specified duration. MOSCAD_SBO_reset(); - Resets the current SBO operation and selection. All SBO DOs are unselected. MOSCAD_rm_get_num_sbo_bits (rack_module) - Returns the number of SBO DOs in the specified I/O module. MOSCAD_rm_get_num_sbo_bytes (rack_module); - Returns the number of bytes to allocate for the specified module (one byte for eight SBO DOs.) For more information on SBO routines, see the ACE3600 RTU ‘C’ Toolkit User Guide. For more information on using SBO DOs in the user application, see the ACE3600 RTU ‘C’ Toolkit User Guide and Appendix B: Ladder Diagram Language in the ACE3600 STS User Guide. For details on the SBO DO module, see the ACE3600 RTU Owner’s Manual.

7

ACE3600 I/Os

I/O Expansion Before reading this section and implementing the I/O expansion feature, please consult the detailed description in the ACE3600 RTU Owner’s Manual. I/O expansion is not available for ACE IP Gateway units or IRRInet-ACE RTUs. I/O expansion is available for ACE3600 RTUs from firmware version 13.00.

I/O Expansion Frames in the ACE3600 Database The ACE3600 application database includes information on the RTU components, including expansion frames (up to 13.) Some information appears per RTU (for example the error logger has an indication for all expansion frames) and some information appears per frame. Two new dedicated system tables, the Expansions Reserved Flags and Expansions Reserved Values, monitor and control important system flags and values of a single expansion frame. Likewise, two columns of the Main Power Supply system tables display values of a single expansion frame. Before using any columns in the Expansions Reserved Flags or Expansions Reserved Values system tables, or the expansion related columns in the Main Power Supply tables (whether to scan in or scan out), the user application must first call the GtExDt ladder call or the MOSCAD_GetExpData ‘C’ Toolkit function to set the desired expansion frame to be the current frame. After that call, the relevant flags/values will be displayed in the database. For further details on the database tables, see Appendix C: Database Tables and Data Types of the ACE3600 STS User Guide. For further details on the MOSCAD_GetExpData ‘C’ Toolkit function, see the ‘C’ Toolkit for MOSCAD Family RTUs manual.

I/O Expansion Configuration A number of I/O expansion parameters and advanced parameters can be configured. A predefined port configuration ‘I/O Expansion Comm.’ is provided for Ethernet communication over LAN using a predefined static IP address. Other parameters define the timeouts and IP addresses required for proper communication between the main frame and the expansion frame(s.) For details, see Appendix A: Site Configuration Parameters in the ACE3600 STS User Guide. Note: In an I/O expansion system with an activated firewall, the IP address range of all expansion frames configured in the system must be listed in the firewall approved list, as well as the IP address of the main CPU expansion port. For details, see the Firewall parameter in Appendix A: Site Configuration Parameters in the ACE3600 STS User Guide. These IP addresses are comprised of: 1. the number set in the I/O expansion module’s rotary frame number selector switch (113) plus either 8

ACE3600 I/Os

2. the ‘Expansion module first frame IP address’ advanced parameter (if it is not 0.0.0.0) or the Self IP address from the 'ETH1->I/O Expansion Comm. port configuration (if the advanced parameter is 0.0.0.0). For example, in a system with thirteen frames, the IP address range might be 10.100.100.100 (main CPU) to 10.100.100.113, or 0.0.0.0 to 0.0.0.13.

Time & Sequencing Synchronization of I/O Expansion In a system with I/O expansion, the expansion modules automatically update the time from the main CPU. This date and time information is used for event timestamps, etc. Each expansion module is synchronized to the main CPU’s time while taking into consideration the different time drifts which are typical of the main CPU and of each individual expansion module. Any change in main CPU’s date and time is immediately transferred to the expansion modules. In addition, the Time & Sequencing mechanization ensures that the event timestamps are sequenced in chronological order. When the main CPU synchronizes the expansion module, an extended time synchronization frame is created in the main CPU (master) to be dispatched to the (slave) expansion modules in the system. The sequencing mechanism ensures that time tags and timer events are sequenced properly in chronological order. An advanced parameter ‘Main to expansion frame TX delay Time’ determines the number of microseconds that represent the time synchronization packet delay on its transit from the main CPU to the expansion frames. Please note that the time synchronization packet delay is also affected by the number of Ethernet switches on the route between the main CPU and the expansion frame. The synchronization mechanism described above is the default and the recommended one. Alternatively, the expansion module can use the main CPU as an NTP server for time synchronization. To do so, the following parameter must be set: •

The ‘Expansion module sets main frame CPU as NTP server’ parameter (Advanced -> I/O Expansion Manager) should be set to Enable.

If the user uses the main CPU as an NTP server for time synchronization, the sequencing mechanism is still performed by the main CPU and the time is synchronized via NTP.

9

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 singleand 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. In systems with I/O expansion, Automatic Recognition can detect I/O modules in the main frame and in expansion frames. If the ETH1 port to which the expansion frames are connected is configured as “Not Used”, only I/O modules in the main frame will be detected. If the ETH1 port to which the expansion frames are connected is configured as Static LAN or I/O 10

ACE3600 I/Os

Expansion Comm., I/O modules attached to the main frame and expansion frames will be detected. Expansion frames with no I/O modules can also be detected.

11

Power Management The ACE3600 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. IMPORTANT: It is the responsibility of the user when defining the application to operate the RTU in accordance with its power management requirements. For example, if the user tries to transmit data over a communication interface which has been powered off, the transmit will fail (as it would in the case of a disconnected cable.) The following RTU components can be controlled using power management: • I/O modules - Put an I/O module to sleep or wake up an I/O module according to the user application request; retrieve an I/O 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. • LEDs – Disable LEDs after a pre-defined timeout. The following system database tables control the power management: CPU Power Supply [id:233], Main Power Supply 1 [id:234] and Main Power Supply 2 [id:235]. Also, DI and DO tables can control the power management of DIs and DOs, respectively. For details on ‘C’ functions used in power management, see the ACE3600 “C” Toolkit manual.

Configuration A number of power management: configuration parameters are defined in the STS site configuration, including LEDs operating mode, timeout for switching the LEDs off, and size of the power manager’s message queue. For details, see Appendix A: Site Configuration Parameters in the ACE3600 STS User Guide.

12

Power Management

Constraints Activities on the power supplies have latency (either because they are done through SPI communication, or because it takes time for the power supplies’ hardware to stabilize.) Therefore, a request to manipulate such a power supply is not immediately served. On the other hand, we 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.

13

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. It is recommended to always use the Safe Firmware Download. A similar check 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.

14

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, which is a layer about Intel® FDI.) 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. File ID Description

File ID Description

0

Ladder Application

33

X25 Address Table

1


34

'C' Application Parameters without reset

2

PLC 1

35

Compressed Files

3

PLC 2

36

RDLAP Modem IDs Table

4

PLC 3

37

MAP27 Address Conversion Table

5

PLC To Master 1

38

NTP Configuration

6

PLC To Master 2

41

Feature File

7

PLC To Master 3

42

Modem Configuration PI1

8

Phone Book

43

Modem Configuration SI1

9

Sites Table

44

Modem Configuration SI2

10

'C' Application

45

Encryption File

11

Application Source

49

Modem Configuration PI2

13

TCP/IP Configuration

50

FPGA file for IO module

26

MOSCAD ACA Code

51

Predefined IO module values

27

MOSCAD ACA Data

53

Temporary Configuration File

29

'C' Application Parameters

56

Network Source File

30

Site Configuration

98

ACE Default Configuration

31

NetMon 'C' Application Parameters

100

Remote System File

15

Flash File System

File ID Description 32

File ID Description

IP Conversion Table

In addition to user flash files, the user application can create log flash files (File ID #55) during runtime.

User Generated Flash Files Most of the files created and used by the STS are stored in the flash memory in a format which is meaningful to the utility, and not to the user. The two files that are meaningful to the user and should be accessible to the user application are the ‘C’ Application Parameters with Reset files (File ID #29) and the ‘C’ Application Parameters without Reset files (File ID #34). These files are created by the user off-line (not during runtime) and are the responsibility of the user. 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).

Accessing Flash Files The ACE3600 RTU ‘C’ Toolkit services enable the user application to access flash files by either file ID (e.g. 29) or by filename (e.g. MyCfile.29). Where one instance of a file exists, it can be accessed by file ID. Where more than one instance exists (e.g. MyCfile.dat and MyCfile.txt) it should be accessed by filename. The ‘C’ application can also retrieve the size of the flash file by filename. 16

Flash File System

Writing Flash Files When the user downloads a file to the flash, all new data is saved as a temporary file (fileID.tmp). The new file is validated by the system to ensure data integrity. If validation succeeds, the temporary file is renamed (e.g. Myfile.). If a file of that name already exists in the flash memory, it will be erased and replaced with the new file. 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. Note: There is no backup of old file versions. 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.

Logging Flash Files User logging flash files (e.g. database history files) are created and maintained by the user application. The file ID of user logging flash files is 55. The format of the files is determined by the user. 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.

Flash File Headers All files in the flash memory include a 64 byte file header added automatically by the system while the file is burned to the flash. The header includes information such as CRC, file name, and the date and time the file was downloaded. When a flash file is read, the size of the file which is returned includes the size of the header. To calculate the size of the actual contents of a flash file (e.g. to copy the file contents to a buffer), you must subtract the size of the header. 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. 17

Flash File System

Flash Files Diagnostics Software diagnostics on the flash file system can be retrieved using the STS SW Diagnostics and Loggers, Device MFFS. Level 0 provides information on the actual files in the flash file system, and Level 3 provides information on the space available and in use in the flash file system. 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.

18

Database Backup The ACE3600 Database Backup feature stores user-defined blocks of user application data in nonvolatile (flash) RTU memory and later restores them to RAM. This ensures that critical data is not lost, e.g. after a power failure. Stored blocks can also be removed from the flash memory. Up to 127 backup blocks (one for each user table) can exist in the flash at one time. The database backup is meant to back up critical information, not to provide a periodic snapshot of the database. Backup is intended for user tables. System tables and constant tables cannot be backed up. Because writing to the flash is relatively slow, frequent backups can impact performance and backups may not occur at the desired intervals. In addition, constant storing and removing of backup blocks increases the fragmentation of the flash which may slow the firmware access to flash files.

Database Backup Operations The user defines each critical data block - a block of cells (a number of rows/columns) in a given table which are to be backed up. A special BlocksToBackup user table is defined in the database with an entry for each block. Only one block can be defined per table and the table index for that entry is the block number. For each block, the user defines the interval at which the block should be backed up. The backup process begins once the application is compiled and downloaded to the RTUs with the ‘Reset and Load’ option. The three backup operations can be performed automatically by the firmware or on demand, from the user’s ladder application. 1. Store Block operation •

When performed by the firmware, the block is stored in the flash according to the backup interval defined by the user in the database.

•

When performed using the StorBlock CAL ladder function, one specific block or all defined blocks (255 value) can be stored.

•

The LastStorRslt parameter in BlocksToBackup table contains the results of the last store operation.

•

Each time a block is stored, it overwrites the previous version.

•

On an RTU with secured firmware, the block in the flash is compressed and encrypted. On an RTU with nonsecured firmware, the block is compressed. The naming convention for database blocks is BFilei, where i=block number (which is the index to the BlocksToBackup table.)

19

Database Backup

2. Restore Block operation •

When performed by the firmware, the block is restored after the RTU restarts (after configuration download with reset, after power failure, etc.) The block from the flash is first validated and then written to RAM.

•

After ladder application download with ‘Reset Load’, all the blocks in the flash are validated. Invalid blocks are removed, while the data of the valid blocks is restored to the corresponding database tables in RAM. After ladder application download with ‘Load’, the blocks are validated, invalid blocks are removed but no data is restored to the tables. Each block that is removed is reported to the error logger.

•

When performed using the RstrBlock CAL ladder function, one specific or all defined blocks (255 value) can be restored.

•

If the database structure was changed since the block was stored, the block is removed and not written to RAM. An error message is reported to the error logger.

•

The LastRstrRslt parameter in BlocksToBackup table contains the results of the last restore operation.

3. Remove Block operation •

When performed by the firmware, the block is erased from the flash. This is done when the user erases the flash (including the application and database), e.g. when downloading with one of the Erase Flash options. The block is also removed if its definition in the BlocksToBackup table (e.g., # of rows, # of columns) is incompatible with the related table structure, or if the characteristics of the saved block are incompatible with the related table structure (e.g. # of rows, # of columns, or data types.)

•

When performed using the RmvBlock CAL ladder function, one specific block or all defined blocks (255 value) can be removed. IMPORTANT: Because there is no confirmation and the removal is irreversible, exercise extreme caution when removing one or all blocks from the flash.

•

The STS SW Diagnostics and Loggers, Device DBBKUP device, Level 6 displays those blocks which were found in the flash when the system came up. For more information, see Database Backup Diagnostics below.

For details on performing the operations in the ladder application, see the Backing up the Database section of the ACE3600 STS User Guide.

Database Backup Site Configuration An advanced site configuration parameter ‘Maximum number of backup operations in queue’ appears in the User Application group under Database Backup. It defines the maximum number of backup operations that can be stored in the backup queue.

20

Database Backup

BlocksToBackup Table The BlocksToBackup user table is added by the user to the database. An entry is created for each table block to be backed up (up to 149 entries). When the database is initially saved, the table number of the BlocksToBackup table is saved as DBBackupTblNo in the Reserved Values system table. Note: During database monitoring, the values in the first six columns of the table are read only. Do not modify the values of the last two columns during monitoring in order to avoid incorrect feedback on store/restore operations. The BlocksToBackup table displayed below includes three blocks of cells from three user tables, to be backed up every three minutes.

Table: The number of the table which contains the critical data to be backed up. FirstCol: The first column in the table to be backed up. ExtraCols: The number of successive table columns (after FirstCol) to be backed up. FirstRow: The first row in the table to be backed up. ExtraRows: The number of successive table rows (after FirstRow) to be backed up. Interval: How frequently the backup should be performed, in minutes (e.g. every 3 minutes.) Note: If the interval is set to -1 or 0, no backup is performed. LastStorRslt: The result of the last store operation, which is updated in the table after the operation, whether the operation was automatic or on demand. The possible values are: 21

Database Backup

-1– Initial value (no store has been performed) 0 – Last store OK. 1 – Preparation stage of the last store operation failed. 2 – Write operation of the last store to flash failed. 3 – At least one of the block identifiers is invalid; therefore the last store failed. 7 – Failed to calculate the size of the block to store. Note: For each failed store operation (1, 2, 3, 7) an error is logged in the error logger. LastRstrRslt: The result of the last restore operation, which is updated in the table after the operation, whether the operation was automatic or on demand. The possible values are: -1– Initial value (no restore has been performed) 0 – Last restore OK. 3 – At least one of the block identifiers is invalid; therefore the last restore failed. 4 – Failed to compare stored block's identifiers in the flash to its identifiers in the current ladder's backup table 5 – Last restore failed because failed to load block contents to its related table. 6 – Cannot restore block because there is no stored block. 7 – Failed to calculate the size of the block to restore. Note: For each failed store operation (3, 4, 5, 6, 7) a message is logged in the error logger. In the example below, block 5 (i.e. the 5th entry in the BlocksToBackup table) is stored in the flash, restored and then removed.

Database Backup Diagnostics The SW Diagnostics utility STS SW Diagnostics and Loggers, Device DBBKUP provides useful information on the backup blocks and operations. Level 2 displays the contents of the BlocksToBackup table, with additional information such as how many seconds remain until the next backup (which is defined in minutes), and whether 22

Database Backup

all block identifiers are valid (i.e. whether the user defined valid boundaries for the block.) If the block is invalid, it cannot be stored. Level 4 displays flags which indicate whether the last erase of all blocks was done by the firmware or by the user application. Level 6 displays all backup blocks which were found in the flash, at the system startup, prior to system run-time. Some files on this list may have been deleted since system startup. Use this level to identify missing blocks. To view the blocks currently stored in the flash, check the SW diagnostics for Device MFFS Level=0 where each block is named BFilei (where i=block number). Level 255 lists all diagnostics provided for the device at all its supported levels. For specific details of each diagnostic and for relevant error messages, see the Software Diagnostic Output and Error Messages manual.

23

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: • Z coordinate (Z=0,1,...,126) is the user table number in the RTU database • Y coordinate (Y=0,1,...,249) is the row number in the user table that appears under the index (Ind) column • X coordinate (X=0,1,....,7) is the column number in the user table. 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).

24


Definitions Using the FETCH and STORE functions requires the definition of a single-column user table of integer value type, with the following variables.

Note that the order of the variables in the table is mandatory. The variable names shown in the table are recommended. The first three values (Table#, Row# and Column#) represent the coordinates of the required variable in the database. They must be set by the user before calling the FETCH or STORE functions. The FETCH/STORE call return code will be returned in the RetCod variable, as follows: 0 – OK 1 – spare 2 – invalid Z coordinate 3 – invalid Y coordinate 4 – invalid X coordinate When calling the FETCH function, the required data will be put in Data0/ Data1 variables according to the data type (specified by the ColTyp variable), as follows: • If the data is of Bit type (ColTyp=1), the data will be put in Data0 variable according to the following: – If the data is 0, then Data0=0x0 – If the data is 1, then Data0=0xFFFF • If the data is of Value type (ColTyp=2), the data will be put in Data0 variable. • If the data is of Floating Point type (ColTyp=4), the data will be put in Data0 and Data1 variables. Before calling the STORE function, the data to be stored in the database must be set as follows: 25


• If the data is of Bit type (ColTyp=1), the data must be put in Data0 variable according to the following: – If the data is 0, then Data0=0x0 – If the data is 1, then Data0=0xFFFF • If the data is of Value type (ColTyp=2), the data must be put in Data0 variable. • If the data is of Floating Point type (ColTyp=4), the data must be put in Data0 and Data1 variables. For example, to store the value of fl1 (floating point variable) in the Z0,Y0,X0 coordinates, the following rungs should be used: Table# ( MOVE ) Z0

Row# ( MOVE ) Y0

Colmn# ( MOVE ) X0 C

Data0

P

fl1

Y

#4

Store ( CALL ) Table #

#4 is a constant defined in a Constants table. Its value is 4 (4 bytes*8=32 bits). Note: The FETCH and STORE functions are not supported for byte and long types.

26

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. This chapter describes the event-driven Change-Of-State (COS). 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:

27


• TIMETAG – for time-tagged COS. Changes are stored in a time tag logger with the time of occurrence in 1 msec resolution. For further details, refer to the ACE3600 STS User Guide. • EVENT – for event-driven COS, described in this chapter. • TAG+EVENT – for time-tagged and event-driven COS. A combination of the above two types.

Event Driven Mechanism When a COS occurs in one of the digital inputs defined as TgDI, the change is recorded in an event queue, including the rack (frame) number, module number, and input number. 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

millisecond

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).

28


The system can simultaneously handle up to 150 events and timers. If there are more than 150 events/timers, the EvOvfl flag of the Reserved Flags table (one of the System Tables), will be set to 1. In this case, it is recommended to clear the events queue (by calling the StEvnt function), and performing ordinary scan. The system can set timers for up to 10 seconds. If no event is read during this period of time, the timer will be turned off, and the EvOvfl flag will be set to 1. It is the user's responsibility to reset this flag to 0. For operations that require delay, the RTU provides the SetTmr function. The end of the timer is regarded as an event. Note that in systems with I/O expansion a certain delay is involved from the time that an event occurs in an I/O expansion frame until it is available to the GtEvnt function. See the ‘Timer event main frame delay time’ parameter in the Timer Event section of Appendix A: Site Configuration Parameters.

Event Driven Tables The Event Driven software includes one System Table, named PRMEVENT. When you open the PRMEVENT table, the following is displayed.

The PRMEVENT Table includes the following parameters: • ___Typ – defines the type of event, as follows: 0 - there is no event in the queue (all other parameters are meaningless). 1 - there is an event in the queue (see other parameters). 2 - the event is caused by a delay timer (set by the SetTmr function). 3 - The RTU's time was set by the STS (using the STS Date & Time utility or Sync command). 29


4 - The event is a power failure report. 5 - The existence of the time's parameters in the TmMost and TmLeas columns, is a result of calling the Time function. • ___Tbl – the table number in the RTU database. • ___Row – the row number in the table (___Tbl). • ___Col – the column number in the table (___Tbl). • ___Bit – the current status of the input. • ___Val – the value for the timer (in x10 msec). • ___TmMost – a four byte real number. Represents the following: Day, Month, Year and Hour (1 byte each). • ___TmLeas – a four byte real number. Represents the following: Minutes, Seconds and milliseconds. 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.

How to Use the Event Driven Software The RTU provides you with three functions in order to implement the Event Driven concept, as follows: • GtEvnt – to retrieve an event from the event queue. • StEvnt – to perform various functions, as follows: ♦

0 – to clear the event queue (set value to 0).

♦

1 – to disable the event-driven mechanism (set value to 1).

♦

2 – to enable the event-driven mechanism (system default) (set value to 2).

• 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.

30


Part of MAIN process StEvnt ( CALL ) #2

(1)

GtEvnt ( CALL )

(2) __Typ (3)

__Tbl

Procs1 ( JSP )

= #0 __Typ

(4)

#9 __Tbl

Procs2 ( JSP )

= #0 __Typ

(5)

#11 __Tbl

Procs3 ( JSP )

= #0

#13

As part of the MAIN process, the above rungs check that an event has occurred, and fulfilling certain conditions, activate appropriate subprocesses. The above rungs are described below: Rung 1:

The StEvnt function is called with a parameter of 2 to enable the Event Driven mechanism. It is recommended to put this rung in the Init process.

Rung 2:

The GtEvnt function is called; the system retrieves an event from the event queue into the PRMEVENT table, including the event type, table number, column number, row number, and data of COS.

Rungs 3-5: These rungs check the ___Typ variable and the affected table number; if ___Typ is not 0 (meaning that there is an event in the queue), the system jumps to perform a specific process according to the table number. For example, in rung 4 the system jumps to the Procs2 subprocess since the table number is 11.

The rungs below describe the use of the timer function of the Event Driven mechanism.

31


Part of Procs2 subprocess I ( MOVE ) __Row

(1) __Typ (2)

Inp2, I

Inp1, I /

Send2C ( JSP )

#1 Inp2, I

Inp1, I

/

__Typ

Inp1, I

Inp2, I

Inp1, I

Inp2, I

/

/

(3)

__Val ( MOVE ) #30

#1

__Typ

SetTmr ( CALL )

Send2C ( JSP )

(4) #2

( RET )

(5)

Rung 1:

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.

Rung 5:

Returns to the MAIN process.

In the MAIN process, you should add appropriate rungs to perform a loop, that checks if there are additional events in the queue.

32


Reading the TmMost and TmLeas Columns The following rungs demonstrate how to read the time parameters from the PRMEVENT table. The time parameter columns in the PRMEVENT table has two variables with seven parameters each. When a specific parameter is required, the user should use the rotation functions LSL or LSR (see Appendix B: Ladder Diagram Language in the ACE3600 STS User Guide) as needed. 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: Data type: Integer Value Ind 0 1 2 3 4 5 6 7 8 9 10 11

Name Myear Mmonth Mday Mhour Mmin Msec Mmsec

(int) Value

Mv1 Mv2 Lv1 Lv2

Mv1, Mv2 (for TmMost) and Lv1, Lv2 (for TmLeas) must be consecutive. Step 2. Define the following constants: Data type: Int Constant Ind 0 3 4

Name #4 #255 #8

Value 4 255 8

33


Step 3. Move the values as follows: 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

34


Mmin ( MOVE ) Lv1

Mmin ( LSR ) #8 A

Msec

N

Lv1

D

#255

Mmsec ( MOVE ) Lv2

Rung: r8

35

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.

Fast Event Definition and Configuration Using the ACE3600 STS, the user can define the number of triggers, the number of fast processes per trigger, and the size of the fast events queue. 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. DI filtering (sampling to ignore spikes) and AI filtering (averaging of successive readings to compensate for slight changes in analog readings) is generally defined in the advanced I/O parameters during site configuration. In addition, APIs in the C toolkit enable the user to change the filtering definitions during runtime.

36

Fast Events

Fast Event Scheduling An application which is constantly involved in fast scans and triggers, or a fast process which is too time-consuming, may load the RTU to the point where it cannot function properly. The proper balance between fast events and other runtime tasks should be found to ensure that the system balance and scheduling are not impacted. In addition, the system keeps track of the execution times of the fast processes and will produce an alert if they are too time-consuming. 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.

Enabling/Disabling Fast Events Triggers for fast events are enabled/disabled from ladder applications (using the TEN/TDS operators) and from ‘C’ applications (using the MOSCAD_fastevent_enable_trigger, MOSCAD_fastevent_disable_trigger services.) T Proc E Trig N P1

T Proc D Trig 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 E N

Proc1 FE_DI_COS DI,x

enables process Proc1 after DIx goes to state DI-COS. T E

Proc1 FE_PB_UP

N

PushB2

enables process Proc1 after pushbutton PB2 is pressed. 37

Fast Events

T E

Proc1 FE_DELAY

N

#10

enables process Proc1 after delay of 10 seconds.

Monitoring of Fast Events The user can monitor both the triggers and the fast processes, using either Process monitoring in the STS Application Programmer (for ladder applications) or diagnostics APIs (for C applications.) 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 userdefined 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.

Fast Events Diagnostics Software diagnostics on fast events can be retrieved using the STS Software Diagnostics and Loggers utility, Device F_EVNT. 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. No diagnostics are provided for timer delay triggers.

Testing Fast Events When programming an application with fast events, run several tests to determine the time required by the application actually needs when running in the unit. Use the F_EVNT diagnostics (e.g. ExecTm, Max ExecTm, and TmException) to verify that the fast process executes without monopolizing system resources and choking the unit.

38

Fast Events

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. In the event that a process monopolizes system resources and chokes the unit, a dump is made to the error logger before the unit restarts. Once the unit has started up again, check the error logger to identify the problem. Focus on the lines after “Reboot handler:” until “prv_userrom_exec”. The figure below depicts such an Error Logger entry.

If, for some reason, the system is unable to initialize the fast event feature, the first line in the F_EVNT level 0 diagnostic will indicate that ‘Fast event feature (F_EVNT software device) disabled by system.’ Contact product support group.

Fast Events and Automatic Recognition When the RTU is configured for ‘Auto I/O modules recognition at startup’, no I/O configuration is defined for the site, because the unit identifies the I/O modules automatically. Therefore, the ladder application will not include an I/O link table mapping the actual I/Os to the application database. When programming a ladder application with DI fast events, variables representing DI triggers are required as parameters to the TEN/TDS operators. If you want to use DI fast events in a unit configured for Automatic Recognition, do the following: 1. In the site view, click on Upload. 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. 39

Fast Events

6. In the I/O link table, link the trigger variables to the actual DIs. 7. Compile and download the ladder application to the unit. For more information on Automatic Recognition, see Automatic I/O Recognition.

40

RTU and Power Supply Redundancy The ACE3600 CPU and power supply redundant configuration enables installation of two redundant CPUs (CPU3680 only) and two redundant power supply modules. The CPU redundancy feature is only supported by the CPU 3680 module, which enables motherboard Ethernet interconnection between the two CPUs. The CPU redundancy ensures continuous RTU operation if one CPU fails. The redundant power supply configuration ensures the supply of the required RTU voltages when one of the power supplies fails. Redundancy Definitions: •

Primary CPU/power supply – Leftmost CPU/power supply

•

Secondary CPU/power supply – Rightmost CPU/power supply

•

Active CPU – the CPU that controls the I/O modules.

•

Standby CPU – the CPU that does not control the I/O modules

The ACE3680 RTU can be configured with redundant CPUs to ensure that RTU operation (monitoring, control, etc.) continues uninterrupted in the event of a failure. Two CPUs are located in the RTU frame, one primary and one secondary. One CPU is active and controls the I/O modules, while the other is on standby. The active CPU can update the standby CPU (date, time, database tables, etc.) in order for the two to remain synchronized. The standby CPU continuously monitors the active CPU to make sure it is operational. If the primary CPU fails (e.g. power falls below a critical level) or if the CPU is restarted due to configuration/ application download, the secondary CPU becomes active and controls the I/O modules. When the failed CPU is repaired or replaced, it becomes the standby CPU. The two peer CPUs share a common (logical) site ID. In addition, each has a private ID (site ID± 1.) These IDs are visible in both the site view and system view. When a site with redundancy is created, all three IDs must be available. If one of the IDs is in use, the common site ID cannot be used. Because a site ID must be between 1-65287, the common site ID cannot be less than two. Note: As with non-redundant RTUs, if you change the site ID in the STS, you must also change the site ID in the RTU using the Downloader. The two CPUs are connected via the RTU motherboard using an internal Ethernet link. This link is defined in the STS between the internal redundancy Ethernet port (INTR1) on each peer. The MDLC link name must be identical for both peers and unique for each set of peers within the system. The INTR1 port is not displayed in the STS unless redundancy is configured. Its parameters are equivalent to those of a Static LAN port. When a redundant site is added to the system, new entries are added to the generic network table for each redundancy peer, with the private ID as the Site ID. The list of links, including the IP link for ports INTR1, will appear. Note: IRRInet-ACE RTUs do not support RTU redundancy. In the figure below, the two peer sites are attached and marked with a yellow circle, half of which marks each peer. Line 11 is the MDLC link used to connect the two internal ports. 41


Redundant RTU Site Configuration By default, the ACE3680 CPUs are not set for redundancy. Redundancy can be set in the STS using the Support Dual CPU field. When a site is defined as redundant, it is set to Primary, and the STS generally creates the peer site automatically. The peer CPU can also be created later when customizing the site configuration. Redundancy support can be removed, in which case the peer CPU is deleted. When a redundant site is deleted, the STS will offer to delete its peer at the same time. Redundant site configurations can be stored in the gallery and new sites can be created from the gallery. When an I/O module is dragged to a primary site, it will also be defined for the peer site, if such exists. An I/O module cannot be dragged to a secondary site when both primary and secondary exist. An internal Redundancy Primary or Redundancy Secondary port can be dragged to a site only if the site supports redundancy. A Redundancy Primary port cannot be dragged to secondary site and vice versa. Initially when a redundant site is created in the STS, the site configurations (I/O module assignment, port definitions, advanced parameters, etc.) created for each CPU are identical, aside from the site IDs and primary/secondary status. Subsequent changes to the port configuration (other than the MDLC link name) must be applied separately to the peer site. IMPORTANT: Redundant sites support I/O expansion but are limited to 12 expansion frames. Redundant sites support Automatic I/O Recognition in a limited fashion; the standby CPU can only detect the frames that are registered in active CPU.) No changes made to a redundant CPU (advanced site configuration parameters, add-on files, ports except INTR1 MDLC link, set date/time, cleared Error Logger) are automatically applied to the peer CPU, except I/O module assignment and Site ID change. A redundant site may be copied. If the site has a peer, the STS offers to copy both sites. When redundant sites are copied and pasted, the redundancy link name, as well as site ID and site name(s) must be redefined. During site definition, the CPUs can be switched from Primary to Secondary status and vice versa. In a redundant site, the following elements of the standby CPU cannot be changed: •

I/O module configuration

42


•

Site ID

•

Redundancy parameters (when both peers exist. When only the secondary site is defined the redundancy parameters can be changed.)

•

I/O Expansion Module advanced parameters

For more information on configuring sites using the STS, see the Operation chapter of the ACE3600 STS User Guide.

Redundancy Advanced Parameters The ‘Maximum RAM size for copying tables from Active CPU to Standby CPU’ parameter appears in the Redundancy advanced parameter group when redundancy is supported. This defines the maximum size of memory used when copying database tables from the redundant CPU to its peer. The ‘Addr. range response for 'All RTU simulation' ’ parameter appears in the Network advanced parameter group. For redundant sites, this parameter is set automatically by the STS to -1 for the primary and +1 for the secondary CPU. These values can be changed by the user as long as the range for the primary is between -1 and -100 (cannot be a positive number) and the range for the secondary is between 1 and 100 (cannot be a negative number.)

Redundant RTU User Application The user applications running in the primary and secondary CPUs are responsible for performing required activities per the CPU status (Active or Standby). To ensure data integrity when CPU switchover occurs, the user ladder or ‘C’ application program running in the active CPU must continuously synchronize the data in the standby CPU database. To facilitate the database synchronization, use the Tb2Cpy CALL function to copy the required user database tables from the active CPU database to the standby CPU database. 1) In the Application Programmer, define a multiple column ‘Redundancy Tables’ table. (Columns can be of integer value or integer parameter type.) - Column 0 represents the list of source tables to copy from the active CPU database. - Column 1 represents the list of destination tables to copy into in the peer CPU database. Note that table numbers may be different but should have the same properties (type, size, etc.) An entry with table number -1 is skipped, not copied. An entry with an invalid table number will cause the copy to abort and return an error. 2) Fill in the table with the two lists of user table indices. 3) In the Application Programmer, have the user process check the CpuActive variable in the Reserved flags table. If it is 1 (active), then CALL the Tb2Cpy function, passing the table symbol as the single parameter.

43


4) In the user process check the return code of the Tb2Cpy function in Tb2CpyResult variable in the Reserved values table. If it is ‘0’, the tables were copied successfully. See the table below for the full list of return codes: ERR_NULL (0)

Copy successfully ended.

ERR_BUSY (50)

Copy process is busy copying a table.

ERR_NOT_FOUND (62)

Redundancy is not supported.

ERR_READY (51)

Illegal try to copy from standby.

ERR_FORMAT (69)

Illegal table parameter

ERR_TYPE (64)

Parameter table columns are not the correct types.

ERR_DATA (58)

Illegal “source” table

ERR_EMPTY (52)

“Source” table is empty.

ERR_SIZE (54)

Memory required is more than the configuration limit

ERR_MEMORY (79)

Memory allocation problem

ERR_PORT (56)

Communication failure

ERR_ERROR (49)

Unexpected error (internal software error)

IMPORTANT: The ‘C’ application user should verify that the initial copy to memory succeeded and then that the copy from memory to the peer CPU was completed successfully. In the user ‘C’ application, the user can deactivate the active CPU, which will cause the standby CPU to become active. When a user application is attached to both the primary and secondary CPUs, the I/O link and KLV/PDV values must be assigned to each CPU individually. (When I/O link and KLV/PDV are assigned to one peer, they are not automatically assigned the other.)

Redundant RTU Communication You can connect to the active CPU via local connection, via the common site ID, or via its private ID. The active CPU can transmit and receive on the common site ID and on its private ID. Data frames can be routed through the active CPU via the common site ID (if it is defined in the network table) or via its private ID. You can connect to the standby CPU via local connection or via its private ID. The standby CPU can transmit and receive on its private ID, but cannot transmit or receive via its common Site ID on any of its ports. Data frames can be routed through the standby CPU via its private ID only. If you connect the STS to the standby CPU, you cannot read from the active CPU or from a remote site. Note: If the STS is connected to the console port of an expansion module (via RS232), and the peers switch during communication with the expansion module, the communication with the STS is aborted. 44


By default redundant CPUs are created with identical port configurations, but these may be changed. Routing through the standby CPU is useful when the secondary CPU has different communication ports/media than the primary CPU. To enable routing through both the active and the standby CPUs, the generic network table includes the primary and secondary private IDs, and does not include the common site ID. If you want other RTUs to route only via the active CPU (the common site ID), the two redundant peers must have identical ports and links, and the network table must list the common site ID only. In this case, create a copy of the generic network table and replace the two private ID entries with one common site ID (with the same identical link/s as before.) The private IDs must be deleted from this copy of the network table. Download the modified network table to any RTUs which will route using the common site ID. IMPORTANT: The network table downloaded to the redundant peers themselves must include the private IDs. Note: An RTU with the Reserved flag Discom = 1 behaves the same as a standby CPU. Data frames routed using the redundant RTU’s common site ID are always relayed by the active CPU, if the common ID is defined in the network table.

Downloading to/Uploading From Redundant Sites In the event of firmware upgrade to a redundant site, the new system firmware must be downloaded to both the primary and secondary CPUs. The download uses the CPU’s private ID (either Site ID+1 or Site ID-1) per its primary/secondary status. You cannot download firmware to the common site ID. A primary site configuration cannot be downloaded to an RTU configured as secondary and vice versa. Files from a secondary site cannot be uploaded to a primary site and vice versa. If a redundant site is uploaded to the STS and its peer already exists in the system, a message may be displayed that the STS will force required configuration changes (if any) to the existing site.

Hardware Tests of Redundant Sites Hardware test of redundant sites can be performed from the STS. The user can deactivate the active CPU, which will cause the standby CPU to become active. For more information, see the Performing Hardware Tests section in the ACE3600 STS User Guide.

Changes to Redundant RTUs In general the two redundant peers should be kept as similar as possible. It is important not to make changes to one peer (e.g. download a new configuration or application) and not to the other. When changes are made to a site with Automatic I/O Recognition, it is recommended to restart both CPUs at the same time, especially if I/O expansion frames are defined. If redundant peers switch (and restart) and the expansion module is restarted, the expansion module will read the data/configuration from the active main CPU. Data integrity is ensured. 45


If the expansion module is not restarted (i.e. the redundant CPUs are restarted within the ‘Expansion module fail timeout to restart’ timeout,) the guidelines below should be followed to ensure data integrity: •

The I/O link definitions in both CPUs should be the same.

•

The PDV and KLV Values in the both CPUs should be the same.

•

All the Configuration parameters (except ports) should be the same.

46

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.

Routing of Data Frames The network configuration serves as an internal data bank which describes a path to each link in the network. When data frames are to be relayed to another site, the node checks if it has a direct link to the destination. If so, the data is transmitted. If there is no direct link, the unit will use the network map to try to identify another path. 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.) 47


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.

Routing over Alternative Direct Link The Routing of Data Frames section above describes automatic routing between sites which are not directly connected. The system will also perform automatic alternative routing between nodes that are directly connected by more than one direct link (if one of them is failed). In legacy systems, finding alternative communication routes across such systems was performed by the user application. 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 100

PSTN

RTU 3

RTU 4

RTU 5

. . RTU 99

Routing over Direct Link is possible with ACE3600 and the STS, and with the later versions of MOSCAD and the Programming ToolBox. If you upgrade older legacy applications which try to transmit over alternate links, these should be modified to prevent redundancy. When RTU101 tries to transmit to one of the RTUs (1-99), the routing is actually performed by RTU100. The behavior of the routing in the system, when one of the links to the designated RTU is failed, is exactly as described in Routing over Alternative Direct Link above. 48


Routing using Remote Failed Links Table In early MOSCAD systems, if a communication disconnect occurred at a remote link (link distance > 1) from the source (i.e. fail link), and the frame could not be transmitted, the frame was discarded. The transmission could only be retried at the application layer (STS communication, RTU-RTU, Burst.) 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 transmissions 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 49


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 loop shaped network. Using it over a complex multi-loop network may result in communication performance degradation, due to the heavy communication required to maintain the Remote Failed Link Table information. IMPORTANT: When setting this feature, all RTUs in the system must have a firmware version that supports this feature. Note: If the size of the Remote Failed Links table is increased substantially, you may need to increase the ‘Stack size of application manager task’ parameter in the site configuration in the Session category of the advanced parameters.

Using the Time To Live Counter The Time To Live Counter feature prevents continuous transmissions in a loop shaped network. Each frame is supplied with a counter set to the ‘Time To Live preset value’ by the frame originator. The counter is decremented by one each time it passes a node. A node will forward a frame as long as the counter is greater than zero. When the counter reaches zero, the frame is discarded and the diagnostic information is stored. Use the Software Diagnostics device NETWRK Level 11 in the Logger tool to view the information. 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.

Routing using Alternative Path to Local Link When a system has a loop shaped network structure, an alternate routing scheme is also feasible if the destination is on one of its local links. For a specific node, this feature is enabled in the network configuration, using the Alternative Path to Local Link icon in the network table. For details, see Editing a Network Table in the Operation chapter of the ACE3600 STS User Guide. Routing of frames in a loop shaped network over radio zone links (when the Alternative Path to Local Link option is enabled in the network configuration) differs from routing over regular radio links or non-radio links. 50


When a single local radio zone link fails, the system will not necessarily find another path to the destination site via the radio zone link. For example, in the figure below, if Site 100 fails to transmit to Site 200 via RADIO1/1, the system will not consider rerouting via RSlink3 to Site 101 and from Site 101 to Site 200 via RADIO1/1 as an alternative link.

Therefore, it is important to create more than one radio zone between sites, as shown below.

51

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. An MDLC over IP port can be used in one of four ways: 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. 4. IP Gateway connected to LAN. An IP Gateway (IPGW) serves as a front-end for a TCP/IP-based SCADA central and enables it communicate with remote RTUs. The IPGW 52

MDLC over IP Communication

uses a direct LAN connection to the radio infrastructure. It cannot be connected with a packet 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.

Broadcast and Setcalls Most wireless packet data networks do not support broadcast IP. When transmitting a group call (Site 0), a separate frame is transmitted to each site specified in the IP Conversion Table over UDP/IP. If broadcast IP exists, then this IP can be specified in the IP Conversion Table under Site 0 with the proper link ID (port). Sending to Site 0 with that link ID will transmit a single message, through that port, to all RTUs over UDP/IP using that address. Note that in ASTRO IV&D, GPRS, TETRA and most wireless media, this is not supported, so a separate message is transmitted to each site. It is preferable to transmit to each site separately, rather than send this setcall, with a delay around 100-300 milliseconds between one transmission and another. The MotoTrbo digital mode radio system supports broadcast IP. In fact, it is the only way of transmitting setcalls.

New Features for MDLC over IP in ACE3600 The following features are available in ACE3600 that are not available in legacy MOSCAD RTUs and IP Gateway. These features apply to Ethernet static, Ethernet DHCP, and RS232 PPP port types.

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.

IP Conversion Table Enhancements An IP conversion table can be assigned to each RTU/FEP. It maps each site ID+link ID (port) to an IP address. The link ID column supports multiple MDLC over IP ports per RTU. Each link ID uniquely identifies the port/IP connection of that RTU. The table enables the MDLC over IP port to transmit MDLC packet to its destination based upon its site ID and link ID (port). 53


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.

Using Host Names Sometime it is necessary to refer to an RTU or FEP using a host name rather than a numeric IP addresses. Any MDLC over IP port (Ethernet or PPP) has that option, however it is the responsibility of the user and network to make sure this is supported. 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,

Configuring NTP Servers An Ethernet or PPP port can be configured for NTP protocol (NTP is UDP port number 123.) In this case, the RTU will retrieve its time from a set of NTP servers specified by the user. The clock offset between the RTU and these servers depends on network delays, and may be up to 100 milliseconds in some wireless media. The clock offset on LAN in the same Ethernet network is approximately 1 millisecond. 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.

54


User Protocol over IP Both Ethernet and PPP ports provide an interface for a user application written in the ‘C’ Toolkit using MOSCAD_socket() functions, also known as “User protocol over IP”. An MDLC over IP port can serve a user application at the same time as it serves MDLC which is built in the socket API. MDLC takes one logical UDP port number (2002 by default); other applications can use other TCP or UDP port numbers. For more information on the ‘C’ Toolkit socket functions, see the ACE3600 RTU ‘C’ Toolkit User Guide.

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.

MDLC over IP Port Routing In the example mentioned in Dynamic IP Address above, for RTU-to-RTU (modem to modem) communication, set ‘Enable routing of MDLC over IP port’ parameter in the FEP. Then assign to the RTUs an IP conversion table which list the RTUs’ site IDs as having the FEP IP address. When one RTU transmits to another, the transmission will go through the FEP which will route it to its destination, without the need of a network configuration. 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.

Downloading Modem Configuration Files A modem configuration file (.stm) used for programming a modem can be downloaded to a port configured for MDLC over IP/PPP or for dialup. The modem configuration files provided with the system can be found in the [C|D]:\STS\config directory. Before downloading the modem configuration to an ACE3600 RTU, you must attach the file to the port using the STS Add-Ons Manager. Specify the port (e.g. Modem Configuration PI1) in the Add-Ons Manager. The modem configuration file will be stored under the [C|D]:\STS\System directory. Attach the file to all sites in the project which require this modem configuration on that port. 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. 55


MDLC over IP/PPP Connections The ACE3600 RTU can include up to four PPP ports - two on-board (SI1 and SI2) and two plug-in RS232 ports (PI1 and PI2.) Each port may be PPP connected to a packet data radio/modem over PPP and have its own link ID. Several RS232 over PPP connections are supported: •

MDLC via IDEN modem (e.g. iM1000, iM1500)

•

MDLC via Standard modem (e.g. GPRS g18 data modem.) See MDLC over Standard Modem Setup for configuration details. A modem configuration file must be attached to the site and downloaded to the RTU when using this connection.

•

MDLC via Tetra radio. This is similar to Standard modem. See MDLC over Tetra Setup for configuration details. When using a Motorola radio (e.g.MTM700), no modem configuration file needs to be downloaded.

•

MDLC via Null modem. This is suitable for direct cable connections over PPP with devices such as Terminal Servers, wireless modem, etc. Depending on the modem used you may or may not need to download a modem configuration file.

•

MDLC over ASTRO IV&D. (e.g. XTL5000) See MDLC over ASTRO IV&D for configuration details. When using the ASTRO IV&D (Integrated Voice & Data) connection, no modem configuration file needs to be downloaded.

In order for a variety of modems to be used, a modem configuration file is downloaded to a specific port configured for MDLC over IP. The modem/radio can also be diagnosed using AT commands specified in that file. For MDLC over IP this feature is applicable to all connections: Standard Modem, Null Modem, Tetra, iDEN, and ASTRO IV&D. Note: The same modem configuration file can be used when configuring a port for MDLC over IP or when configuring the port for dialup. For details, see Modem Configuration File below. Note that for iDEN, Tetra and ASTRO IV&D the modem configuration is not required, since the firmware already has these commands built in.

MDLC over IP/LAN Connections The ACE3600 RTU can include one on-board 10/100 Ethernet BaseT port (ETH1) (not in ACE3610) and up to two plug-in 10/100 BaseT ports (PI1 and PI2.) Each Ethernet port has its own link ID and can be connected to the same or to a different network mask. An Ethernet (LAN) port can be configured in one of the following modes: •

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.

56


MDLC over IP/Remote NDIS Host Connection The ACE3600 RTU (ACE3680) and ACE IP Gateway (CPU 4600) include two USB Type A host ports for MDLC over IP communication via the MotoTrbo digital mode radio system. Up to two different MotoTrbo radios (XPR4350/4380, DM3400, XiR M8220, DGM4100, XPR5550) can be attached to the two USB host ports at one time, as long as the radios have different IP addresses on a different network mask (e.g. 199.19.10.1 and 199.19.11.1). The Remote NDIS Host connection supports MDLC and ‘C’ Toolkit API over IP. No other USB devices or USB Hubs may be connected to the USB port. The USB HU1 or HU2 ports are true IP physical ports. See MDLC over MotoTrbo for configuration details.

MotoTRBO Digital Radio Topologies An ACE3600 system with MotoTrbo digital radio can be organized in three possible topologies: •

Direct Mode (DMO)

•

Single Repeater

•

IP Site Connect

(No MDLC group call allowed.)

STS PC Communication Setup Options In order to communicate with RTUs and IP Gateways, the ACE3600 STS computer can be connected in one of three ways. The Communication Setup utility is used to configure the setup. 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. When connecting to a remote RTU/IPGW via MotoTrbo, set the Local IP Address to that of the remote RTU connected to MotoTrbo radio. For information on the setup and constraints, see Appendix C: PC Communication over MotoTrbo. 3. Peripheral interface IP 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. 57


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.

MDLC over IP Setup The general setup described below applies to all variations of MDLC over IP where the RTU is connected to the IP via phone/modem or LAN. For the actual values to be assigned in the site configuration (port type and parameters) refer to the appropriate setup section for variation. 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 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.

MDLC over IP Site Paging A paging mechanism is available in each site (peer) to make MDLC over IP more reliable. (This feature is the same as in Toolbox 9.54 and MOSCAD 9.25.) Paging a site before transmitting MDLC data to it over IP, guarantees that the site is reachable. This is necessary 58


because MDLC over IP does not have a confirmed type of link in which the peer acknowledges received packets (as opposed to other types of MDLC ports). It relies on the radio to have a link layer that will guarantee a ‘best effort’ delivery, and thus avoids overloading the channel with excessive traffic. A site is paged by sending it a poll request and awaiting a poll reply. During this time, the RTU can continue to transmit to other sites (and receive transmission from other sites). If the site responds with a poll reply, or any other MDLC data, it is considered as reachable, and all pending transmissions are sent to it immediately. Further transmissions will be sent to it as well without paging until the site is declared as failed. If an ‘ICMP Destination Unreachable’ message is received or if the site does not respond to paging for a configurable poll interval, it will be polled again for a maximum number of polls. If there is still no response, the site is considered to be failed, and the network layer is notified so any pending transmissions can be redirected to an alternative route. If subsequent transmissions are to be sent to the site through an MDLC over IP port, paging will be performed again before actual transmission takes place. The Site Paging mechanism can be enabled or disabled. When using modem devices iDEN, Tetra, Standard and Null modem, all sites are reset to unknown state when disconnecting and reconnecting the modem/cable to RTU. For ASTRO IV&D because no DCD exists, the RTU detects the lack of signal from the port several seconds (40 by default) after the data cable is disconnected, or the radio is powered off. As a result, following this operation, paging will be performed before a transmission is sent. With non-modem devices, such as MDLC via Ethernet, reconnecting cable will not cause paging to be performed. Three parameters (Check Alive timeout, Poll interval , and Maximum number of polls) have been added to the Advanced Link layer for paging purposes and are described in detail in the Advanced Link Layer section under MDLC via iDEN. For each variation of MDLC over IP, the parameter setting may vary.

MDLC over LAN/Ethernet The ACE3600 RTU can communicate over Ethernet media, via the onboard Ethernet port (where relevant) or 10/100BT plug-in ports. The figure below illustrates an example of a SCADA system with IP Gateway and ACE3600 RTUs connected to Ethernet LAN:

59


SCADA Central

STS Ethernet 1

LINE 1 RS-232

IP Gateway

STS

IP Network

Ethernet 2

Ethernet 3 10BaseT

10BaseT RTU-IP1

RTU-IP2

10BaseT RTU-IP3

RS-232 STS

on Ethernet on-board Port

on Ethernet Plug-in Port

With SCADA systems, the ACE3600 RTU can be connected to Ethernet/LAN as an FEP (FIU) for a SCADA, and an RTU. It communicates with MDLC over IP between FEP/IP Gateway and RTU. The IP 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 numeric IP address. In this case the operator assigns a host domain name to the FEP or RTU. The IP conversion table must include the domain name well. If an NTP server is to be used to obtain the time, the numeric IP address or domain name of the NTP server must be defined. 2. DHCP-supplied reserved IP address – For every ACE3600 RTU Ethernet port, an IP address will be reserved within the DHCP server. The link between the RTU and the 60


reservation will be based on unique ID. In the DHCP Server, set the unique ID. The default unique ID is the MAC address. In the DHCP server, define a reservation for a specific RTU based on its MAC address. 3. DHCP-supplied dynamic IP address – A dynamic IP address is distributed from the DHCP server to the ACE3600 RTUs. The IP address of each ACE device is unpredictable. In this case you will need a DNS server that will resolve the link between the IP address and the RTU. You will have to supply a name for each RTU. This name will be updated within the DNS server along with IP address of the RTU. Within IP conversion table of ACE3600 RTU you will use this DNS name instead of IP address. 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.

Static IP Address Configuration The user should configure the RTU Ethernet port in the site configuration as follows: 10/100 BT, Static LAN, Ethernet, LAN

Static IP Address Link Parameters Self IP Address

Range: 000.000.000.001-255.255.255.254 IP address of the RTU Ethernet port. For information on this and other IP addresses in the configuration, see your network administrator. Default Routing IP Address

Range: 000.000.000.001-255.255.255.254 This serves as the router from the network address to the remote IP network. The IP network mask of this address should be the same as the Self IP address. For example, if the IP network mask is 255.255.255.0 and the Self IP address is 155.9.199.235, then 155.9.199.1 is a valid default routing address. All IP datagrams transmitted to remote networks outside of 155.9.199.xxx will be directed to 155.9.199.1 router. This parameter is optional, in case IP Conversion Table has addresses beyond 155.9.199.xxx for that 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 61


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).

Other Link Parameters Links:

Range: LINE 1-LINE 29. Default: LINE 1 User can assign more than one link name. ACE3600 supports several link names on the same MDLC over IP port. This feature enables RTU #1 that has one MDLC over IP port, for example ETH1, to communicate directly with RTU #2 that has two MDLC over IP ports, LINE1 and LINE2. In this case, assign LINE1 and LINE2 to the RTU #1 MDLC over IP ETH1 port.

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.

NTP Server

As an option 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 occurs every 2 minutes, if not connected to external sync source such as NTP or GPS.

Dynamic Configuration over IP using DHCP 10/100 BT, DHCP Client, Ethernet, LAN

Ethernet ports of the ACE3600 RTU can be configured dynamically using DHCP. Each one of these ports can be configured as a DHCP client. When such a port is configured as a DHCP client, it will receive several vital IP parameters from the DHCP server such as IP address, Subnet mask, Default router, etc.

62


MDLC over DHCP Link Parameters The following parameters must be configured for each IP port in the ACE3600 RTU. The values chosen for the parameters will define the method in which the ACE3600 fits into the network. Links:

Range: LINE 1-LINE 29. Default: LINE 1 User can assign more than one link name. ACE3600 supports several Link names on the same MDLC over IP port. This feature enable RTU #1 that has one MDLC over IP port, for example ETH1, to communicate directly with RTU #2 that has two MDLC over IP ports, LINE1 and LINE2. In this case, assign LINE1 and LINE2 to RTU #1 MDLC over IP ETH1 port.

Host Full Name

Range: free text format. Default: empty string. If user specifies a string, this should be the full name of the port as provided by the DNS Server. The DHCP Server will update the DNS Server when allocating or changing the IP address of that host, keeping it up to date with the recent address of port. This is called FQDN. If a DHCP Server/router does not support this option, a warning will be logged.

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.

MDLC over DHCP and Static LAN Advanced Link Parameters The following parameters must be configured for each IP port in the ACE3600 RTU. The values chosen for the parameters will define the method in which the ACE3600 fits into the network. 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. 63


MDLC over IP port number

Range: 1-65535 Default: 2002 This number is common to all RTUs and IP Gateways connected to this link. This number identifies the MDLC. This is a UDP port number and the provider should be consulted. It is important that this number not be in use as specified by the TCP/IP standard RFC0960. Enable Sync Range: Disable/Enable Default: Disable If this parameter is Enabled, this port can send an MDLC Sync to other RTUs, and receive an MDLC sync. If this parameter is Disabled, this port does not send an MDLC Sync, and ignores received sync frames. It can however forward sync words that were initiated from other Link IDs, or from the STS. It is recommended to use the NTP protocol instead for time settings. Notify IP Address Range: Disable/Enable when connected Default: Enable When enabled, if an RTU’s IP address is changed or obtained from a modem, the RTU will send a message to update its IP Address in all sites. Note: These messages are sent one after the other, and it is not guaranteed they will be delivered and accepted. Enable routing on Range: Disable/Enable MDLC over IP port Default: Disable When enabled, an RTU or FEP can route back MDLC over IP packets received that were destined for a different site ID. When disabled, an RTU or FEP ignores packets received which are destined for other sites. This parameter allows two RTUs to communicate via this RTU, and is useful if they have dynamic IP addresses. Note also that the RTUs need to transmit periodically in order for their IP address to be updated in its IP conversion table. A paging mechanism to each site (peer) in IP conversion table makes MDLC over IP more reliable. The following parameters have been added to Link layer and are optional. For more information refer to MDLC over IP Site Paging.

64


Check Alive timeout in seconds

Poll interval in seconds

Maximum number of polls

Range: 0-65535 sec Default: 35 Specify timeout in seconds from the last reception from a peer. If nothing has been received from the peer during that timeout, it will be paged before the next transmission (see below). This behavior guarantees that a peer will be reachable over IP. If it does not respond, route transmissions to it through alternate routes. Check alive timeout is measured independently for each site in the IP conversion table. If this parameter is 0, a peer will always be considered as reachable, once a single reception has been received from it. This parameter is considered to be 0 regardless of its value if ‘Maximum number of polls’ is 0. Range: 0-65535 sec Default: 10 Specify interval in seconds between polls of peer. When a peer is being paged, a poll request is sent. If no answer is received after that period of time, another poll request will be sent until the Maximum number of polls was sent (next parameter). Poll interval is measured independently for each site in the IP conversion table. If this parameter is 0, a single poll (or no polls) will be sent to the peer according to Maximum number of polls (0 or not.) Range 0-255 Default: 3 Specify the number of poll requests to send in order to check if the peer is alive. When paging a peer, if no response is received, it is polled again. If the peer has been polled for the Maximum number of polls without answering, it is considered as failed, and all transmission are routed through an alternate path.

MDLC over iDEN With SCADA systems, ACE3600 RTUs can be connected to iDEN iM1000/iM1500 modems (OEM version >=35.01.00) to communicate using PPP over iDEN infrastructure to the IP network. Since iDEN infrastructure connects to Local Area Networks (LAN) as well, a LANconnected IP Gateway or FEP can communicate directly with these RTUs over iDEN infrastructure. The iM1000/iM1500 is configured to operate works in various modes, including: 65


•

Packet Data (PD)

•

Circuit Data (CD)

•

Packet Data over Circuit Data (PD over CD)

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 Routing Net

LINE 1 RS-232

IP Gateway

STS

Home Agent

iDEN infrastructure

Interface Router

Base Station

Mobile Data Gateway

LINE 1

iDEN iM1000 Packet Data modem STS

RS-232

RTU-A

iDEN iM1000 Packet Data modem RTU-B

66


IP Gateway/FEP to RTU Communication A datagram transmitted from the IP Gateway is received by the Home Agent (HA) which encapsulates the frame and transmits it through the Interface Router (IR) to the Mobile Data Gateway (MDG). In IP terms, encapsulating a datagram and directing another entity to deencapsulate it, is called tunneling. The MDG de-encapsulates it and extracts its destination IP Address from the IP Header. The MDG then consults a table which maps each IP Address to its correlated iM1000 modem. Using the LAPi protocol, the MDG encapsulates the datagram in a LAPi frame, and transmits it to the appropriate iM1000 modem. The modem may need to be paged before the actual transmission. (See IDEN Modem Session State/Paging below.)

RTU to IP Gateway/FEP Communication When an RTU configured for MDLC over iDEN transmits a datagram towards the IP Gateway, the modem requests a packet channel. When an available packet channel is found, the modem encapsulates the frame in LAPi and transmits it over the air and base station to the MDG. The MDG then extracts the RTU’s datagram from the LAPi frame and passes it to the Interface Router (IR) on the LAN. The IR routes the packet to the IP Gateway using conventional IP routing. Depending upon the LAN topology, datagrams may or may not pass through the HA (which acts as a default Internet router in this case).

RTU to RTU Communication When an RTU transmits a datagram to another RTU’s IP Address, the transmission to the MDG is handled the same way as when transmitting to an IP Gateway. The MDG forwards the datagram to the IR on the LAN. The IR functions as an internet router, routing the datagram to the Home Agent (HA). The HA tunnels it to the MDG (through the IR). which deencapsulates the original datagram and identifies the iM1000 modem address for the destination IP address. The MDG then encapsulates the datagram in LAPi protocol and transmits it to that iM1000 modem as described above. (See IDEN Modem Session State/Paging below.) 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).

IDEN Modem Session State/Paging In order to lengthen battery life and also to allow voice and data operations in a modem at the same time, the concept of session state was defined for iDEN equipment. A modem is dormant or idle when it has not received/transmitted data for some time. Because less communication is required in dormant/idle state, the battery drain is reduced. In this state, it is able to receive both voice dispatch calls/alerts, and paging. 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.

67


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 depends on the topology and state of the network. This may be relevant for some applications involving data sent from one RTU to another.

MDLC over iDEN Setup The general steps of the MDLC over iDEN Setup are identical to the MDLC over IP Setup. 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.

RTU Site Configuration In the Site Configuration, set up either PI1/PI2 or SI1/SI2 as RS232, Async, PPP, iDEN. RS232, Async, PPP, IDEN

Currently the iDEN modem can be physically connected to PI1/PI2 or SI1/SI2. Only one iDEN modem can be used per RTU because its internal IP address is the same. The Advanced parameters should be set as defined below.

Link Parameters for PI1/PI2 or SI1/SI2 Links

Data Speed DNS Servers NTP Server

Range: LINE 1-LINE 29. Default: LINE 1 The user can assign more than one link name. ACE3600 supports several link names on the same MDLC over IP port. This feature enables RTU #1 that has one MDLC over IP port, for example ETH1, to communicate directly with RTU #2 that has two MDLC over IP ports, LINE1 and LINE2. In this case, assign LINE1 and LINE2 to RTU #1 MDLC over IP ETH1 port. Range: 1200 - 115200 Default: 19200 The user may enter three DNS servers, however this step is not necessary since they are learned from the modem. 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 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 an external sync source such as NTP or GPS. Note that NTP servers are never learned from the modem. 68


Advanced Physical Layer The values of these parameters are identical to other variations of MDLC over IP as described above. Format

Port Mode

Optional AT command string

RTS always ON

Number of configuration attempts to reset radio/modem

Wait time after Reset radio [sec]

The valid values are: 7 bits Even Parity 2 stop bit 7 bits Odd Parity 2 stop bit 7 bits Even Parity 1 stop bit 7 bits Odd Parity 1 stop bit 8 bits No Parity 2 stop bit 8 bits Even Parity 1 stop bit 8 bits Odd Parity 1 stop bit Default: 8 bits No Parity 1 stop bit Default: DTR/CTS Support Hardware flow control of the port includes DTR and CTS signals. This additional AT string can be used to enhance the modem just before the modem is returned to online mode after configuration. For more details, see Modem Configuration below. The RTS of the RTU is connected to the modem’s DTR. It is controlled by software, and is On. By default, it is On. Default: 2. Range: 0 to 255. If the RTU fails to configure or register an iDEN modem, it restarts the iM1000/iM5000 modem using AT commands. This parameter determines how many failed attempts to connect modem are required before restarting it. If a modem configuration file was downloaded, the n_failstoreset variable in file overrides this setting. Default: 7 seconds. Range: 0 to 255 seconds. Specify how long to wait after restarting the radio/ modem as above before attempting to configure and register it. If a modem configuration file was downloaded, the SetRtsTimeout variable overrides this setting.

69


PPP echo send max retries

Default: 0 Range: 0 to 255. If not 0 it determines the number of retries to poll the modem if it does not reply. If retried with no response for max retries, the data cable to the modem is regarded as disconnected. For iDEN leave it 0. This parameter is intended to be used when no DCD input signal is provided by the modem. If a modem configuration file was downloaded, the pppechosendmaxretry variable overrides this setting.

If a PPP connection type is used, the following optional parameters exist as well but for iDEN they should be left unchanged. They are intended to support more modems/radios. PPP echo send interval [sec]

PPP protocol compression

PPP address compression

User name

Default: 0 Range: 0 to 255. If not set to 0, it determines the time interval to poll the modem over PPP. If no reply is received within PPP echo send max retries, it will declare the cable as disconnected, and start to reconnect with the modem. For iDEN leave it as 0. This parameter is intended to be used when no DCD input signal is provided by the modem. If a modem configuration file was downloaded, the pppechosendinterval variable overrides this setting. Default: Enable Range: Disable/Enable If enabled, this configures PPP to use protocol field compression as defined in RFC1661. For iDEN leave it enabled. If a modem configuration file was downloaded, the pppprocomp variable overrides this setting. Default: Enable Range: Disable/Enable If enabled, this configures PPP to use address field compression as defined in RFC1661. For iDEN leave it enabled. If a modem configuration file was downloaded, the pppaddrcomp variable overrides this setting. Set the appropriate user name for connecting to the modem when performing PPP authentication. If a modem configuration file was downloaded, the username variable in the file overrides this setting. 70


Password

Set the appropriate password for connecting to the modem when performing PPP authentication. If a modem configuration file was downloaded, the password variable in the file overrides this setting.

Advanced Link Layer ACE3600 supports several link names on the same port. This feature enables RTU #1 that has one MDLC over IP port, for example ETH1, to communicate directly with RTU #2 that has two MDLC over IP ports, LINE1 and LINE2. In this case, assign LINE1 and LINE2 to RTU #1 MDLC over IP ETH1 port. The following parameters are specific for each link name: TX to failed RTU every Range: 0-30 (0 disables) <0: DISABLE 0-30> Default: 3 Min It specifies a period of time in seconds, after which a failed link will be considered as being back in order, provided the value of the Periodic check of failed RTU parameter is set to Disable. If the Periodic check of failed RTU parameter is enabled, it specifies the period of time in seconds after which the Network layer issues a control frame to check the failed link. Periodic check of Default: Disable failed RTU The network sends a control frame to check whether the link is still in "failed" status. The frame is issued if the link has been in "failed" status for the period of time specified in the TX to failed RTU every <0:DISABLE 030> Min parameter. Default group IP Range: 000.000.000.000-255.255.255.255 address Identifies Site ID 0 which is used for Group Call on specific link ID. Get host by name Default: Enable. using DNS This parameter enables host name within IP Conversion Table for the specified link name. If set to Disable, host names cannot be used within that link name in IP Conversion Table.

The following parameters are common to all Link names configured for this port.

71



Enable Sync

Notify IP Address when connected

Enable routing on MDLC over IP port

Range: 1-65535 Default: 2002 This number is common to all RTUs and IP Gateways connected to this link. This number identifies the MDLC. This is a UDP port number and the provider should be consulted. It is important that this number not be in use as specified by the TCP/IP standard RFC0960. Range: Disable/Enable Default: Disable If this parameter is Enabled, this port can send an MDLC Sync to other RTUs, and receive an MDLC sync. If this parameter is Disabled, this port does not send an MDLC Sync, and ignores received sync frames. It can however forward sync words that were initiated from other link IDs, or from the STS. It is recommended to use the NTP protocol instead for time settings. Range: Disable/Enable Default: Enable When enabled, if an RTU’s IP address is changed or obtained from a modem, the RTU will send a message to update its IP Address in all sites. Note: These messages are sent one after the other, and it is not guaranteed they will be delivered and accepted. Range: Disable/Enable Default: Disable When enabled, an RTU or FEP can route back MDLC over IP packets received that destined to a different site ID. When disable, an RTU or FEP ignore packets received which are destined to other sites. This parameter allows two RTUs to communicate via this RTU, is useful if they have dynamic IP address. Note also they need to transmit periodically for their IP address to be updated in its IP Conversion Table.

72


Modem configuration timeout (Sec)

Enable RALP

Get modem status sample time (Sec)

Modem diagnose reply timeout (Sec)

Restart modem when deregistered

Range: 40-255 sec Default: 40 The period of time the network will wait for successful configuration of the modem upon power up of modem or RTU. If within this period, the modem configuration does not complete, RTU marks the port as Failed, though configuration continues. If configuration fails, the modem may not be properly configured. Configuration status can be checked using the Error Logger and Software Diagnostics (LIN1L Level 0, 101. For more details, see Modem Configuration below. Default: Yes Radio Application Layer Protocol. Enables periodic sampling of the modem to get messages about its status (whether the modem is registered in the network and can send/receive packet data over the infrastructure). Modem diagnostics can also be checked using the Software Diagnostics utility. The valid values are: Yes No Like RCP, RALP uses a separate socket from the data socket and works in parallel to MDLC over the air using a PPP connection. Range: 0-255 sec Default: 10 Relevant only if Enable RALP is YES. The period of time to wait between checking the status of the modem (if it is registered with the network and able and to send/receive packet data over the infrastructure.) Range: 10-255 sec Default: 10 Relevant only if Enable RALP is YES. The period of time for the Software Diagnostics to wait a reply from the modem before returning an error. (e.g. LIN1L levels, 102, 103.) Range: 10-255 sec Default: Yes Relevant only if Enable RALP is YES. If Yes, then restart the modem each time it is detected that the modem has been de-registered by the system. This will make the modem more reliable, however MDLC data may be lost when restarting the modem (until it initiates itself.)

73


Disconnect on idle timeout sec

Range: 1- 65535 Default: 0 When specifying a timeout in seconds, the RTU monitors the delay from the last time anything was received from the modem (during PPP mode). If this time expires, this means there is a problem with the modem connection. The RTU will disconnect and reconnect to the modem. If 0, this parameter ignored. Registration life time Range: 0 to 65535 seconds Default: 7200 If not 0, this sets an interval in which a connected radio/modem is deregistered and reregistered for packet data. The RTU adds an offset to this number, which is derived from its site ID, so not all radios are restarted and context activated at the same time. If a file was downloaded, this parameter can be overridden using the regLifeTimeout variable. A paging mechanism to each site (peer) in IP conversion table makes MDLC over IP more reliable. The following parameters have been added to Link layer and are optional. For more information refer to MDLC over IP Site Paging. Check Alive timeout in seconds

Range: 0-65535 sec Default: 35 Specify timeout in seconds from the last reception from a peer. If nothing has been received from the peer during that timeout, it will be paged before the next transmission (see below). This behavior guarantees that a peer will be reachable over IP. If it does not respond, route transmissions to it through alternate routes. Check alive timeout is measured independently for each site in the IP conversion table. If this parameter is 0, a peer will always be considered as reachable, once a single reception has been received from it. This parameter is considered to be 0 regardless of its value if ‘Maximum number of polls’ is 0.

74




Range: 0-65535 sec Default: 10 Specify interval in seconds between polls of peer. When a peer is being paged, a poll request is sent. If no answer is received after that period of time, another poll request will be sent until the Maximum number of polls was sent (next parameter). Poll interval is measured independently for each site in the IP conversion table. If this parameter is 0, a single poll (or no polls) will be sent to the peer according to Maximum number of polls (0 or not.) Range 0-255 Default: 5 Specify the number of poll requests to send in order to check if the peer is alive. When paging a peer, if no response is received, it is polled again. If the peer has been polled for the Maximum number of polls without answering, it is considered as failed, and all transmission are routed through an alternate path.

MDLC Session Logical Channels Advanced Parameters Application layer Stack size of application manager task

Range: 1000-4000 Default: 1300

Modem Configuration Sequence The parameters described above for the iDEN modem are configured through in the site configuration when the modem or RTU is powered up. The RTU sends AT commands to the modem to change its mode to off-line, program the necessary settings, and return it to online mode. This is transparent to the user, but during this time the RTU cannot transmit MDLC via this port. Any data sent is queued until the modem returns to online mode. If the configuration fails, queued data is returned to the network for retransmission via an alternative route. If the configuration fails, it is possible that the modem was not properly configured. The Error Logger and Software Diagnostics should be checked to identify the problem (IPLINK LIN1L Level 0, 101). 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 75


also be required to change the modem identification number and enable the iDEN infrastructure to reset parameters in the modem. These changes should only be performed in coordination with the technical support group. •

Disconnect the modem from the RTU.

•

Connect the modem to a PC running the Applet software.

•

Open the Modem Configurations window.

•

Modify the settings as instructed by the technical support group.

•

Power/cycle the modem.

•

Reconnect the modem to the RTU.

Special AT Commands for the iDEN Modem The following default AT commands are sent by the RTU when configuring the iDEN modem. These commands can be overridden/added by specifying the Optional AT command string in the Advanced Physical Layer parameters in the Site Configuration utility. This string will be sent last to the modem prior to setting it to “online mode” and may override previous settings. 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. ATZ2 – Load profile 2 (packet data) into the modem. AT&D0 – Instruct the modem to ignore DTR, since the RTU does not support it. AT&C1 – Instruct the modem to activate CD in online mode. AT+WV300=1 – Instruct the modem to use its own mobile IP stack. AT+WV302=7200 – Set the modem registration lifetime to two hours. 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+WS46=24 – Set the modem to packet data mode. AT+WS45=4 – The modem will initiate PPP when going online. 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. AT+wvreset – Reset modem via AT command.

76


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. AT+WS53? – Checks the signal quality on a normalized scale (from 0 to 100), where 100 is the best signal, and <75 means it is poor quality. The firmware checks the signal quality before attempting to register the modem. If signal quality is below 75, the RTU will keep issuing this command until getting a better value. If reasonable quality is not reached within Modem configuration timeout (by default it is 40 seconds), the RTU declares the modem configuration as failed. It will retry to configure the modem immediately afterwards. If failed for more than Number of configuration attempts to reset radio/modem times successively, it will restart the modem using the above AT command. AT+IPR= –Sets the modem data speed. By default, the data speed of the iDEN iM1000/iM1500 modem is set to 19200 to match the default data speed of the RTU. The firmware automatically sets the modem data speed to the rate specified by the user for the port. If the data speed of the RTU port is changed, firmware will change the modem speed accordingly. It is recommended that all RTUs operate their modems on the same data speed.

77


MDLC over Tetra With SCADA systems, ACE3600 RTUs can be connected to a Tetra radio. Tetra infrastructure and radio should support packet data. 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 Routing Net

LINE 1 RS-232

IP Gateway

STS

Tetra Infrastructure SW MI

LINE 1

STS

RS-232

Tetra MTP700 radio

Tetra MTP700 radio

RTU-A

RTU-B

The STS can communicate with remote RTUs over IP using the Tetra infrastructure. The PC running the STS is connected to the Tetra radio (e.g. MTH500 radio) or to the RTU. For this 78


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).

MDLC over Tetra Setup The general steps of the MDLC over Tetra Setup are similar to the MDLC over IP Setup. For MTM700, MTM800, a modem configuration file is not required. If a different radio used, a modem configuration file is required. Refer to Downloading Modem Configuration Files above.

RTU Site Configuration In the Site Configuration, set up either PI1/PI2 or SI1/SI2 as RS232, Async, PPP. Select Tetra: RS232, Async, PPP, Tetra

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:

Link Parameters for PI1/PI2 or SI1/SI2 Links:

Data Speed

Range: LINE 1-LINE 29. Default: LINE 1 User can assign more than one link name in the same physical port. ACE3600 supports several Link names on the same MDLC over IP port. This feature enable RTU #1 that has one MDLC over IP port, for example ETH1, to communicate directly with RTU #2 that has two MDLC over IP ports, LINE1 and LINE2. In this case, assign LINE1 and LINE2 to RTU #1 MDLC over IP ETH1 port. Range: 1200 – 115200 Default: 9600 79


DNS Servers

NTP Server

The user may enter three DNS servers. Note that TETRA MTM700 and MTM800 radios do not learn the server information from the modem, so if host names are used in the Customer Enterprise Network (CEN)/LAN, the user should enter this information. On the other hand, most applications do not have host names in the CEN of TETRA. The user may specify up to three NTP Servers. If defined, they will be polled for the time of day every 2 seconds-17 minutes. Expect a clock offset of around 100 milliseconds. The NTP Server can be the FEP on CEN or any PC acting as an NTP server that the user set up in the CEN. If an FEP is used, and it is not connected to GPS, it is up to the user to set its clock. Note that NTP servers are never learned from the modem.

Advanced Physical Layer The values of these parameters are identical to other variations of MDLC over IP as described above. Format

Port Mode

Optional AT command string

RTS always ON

The valid values are: 7 bits Even Parity 2 stop bit 7 bits Odd Parity 2 stop bit 7 bits Even Parity 1 stop bit 7 bits Odd Parity 1 stop bit 8 bits No Parity 2 stop bit 8 bits Even Parity 1 stop bit 8 bits Odd Parity 1 stop bit Default: 8 bits No Parity 1 stop bit Default: DTR/CTS Support Hardware flow control of the port includes DTR and CTS signals. This additional AT string can be used to enhance the modem just before the modem is returned to online mode after configuration. For more details, see Special AT Commands for the Tetra Radio below. The RTS of the RTU is connected to the modem’s DTR. It is controlled by software, and is On. By default, it is On.

80


Number of configuration attempts to reset radio/modem


Default: 2. Range: 0 to 255. If the RTU fails to configure or register a modem, and the modem supports this feature, it can restart the modem using AT commands. This parameter determines how many failed attempts to connect to the modem are required before restarting it. If a modem configuration file was downloaded, the n_failstoreset variable in file overrides this setting. Default: 7 seconds. Range: 0 to 255 seconds. Specify how long to wait after restarting the radio as above before attempting to configure and register it. If a modem configuration file was downloaded, the SetRtsTimeout variable overrides this setting.

If a PPP connection type is used, the following optional parameters exist as well, but for iDEN they should be left unchanged. They are intended to support more modems/radios.

PPP echo send max retries

PPP echo send interval [sec]

Default: 0 Range: 0 to 255. If not 0 it determines the number of retries to poll the modem if it does not reply. If retried with no response for max retries, the data cable to the modem is regarded as disconnected. For iDEN leave it 0. This parameter is intended to be used when no DCD input signal is provided by the modem. If a modem configuration file was downloaded, the pppechosendmaxretry variable overrides this setting. Default: 0 Range: 0 to 255. If not set to 0, it determines the time interval to poll the modem over PPP. If no reply is received within PPP echo send max retries, it will declare the cable as disconnected, and start to reconnect with the modem. For iDEN leave it as 0. This parameter is intended to be used when no DCD input signal is provided by the modem. If a modem configuration file was downloaded, the pppechosendinterval variable overrides this setting.

81




User name

Password

Default: Enable Range: Disable/Enable If enabled, this configures PPP to use protocol field compression as defined in RFC1661. For iDEN leave it enabled. If a modem configuration file was downloaded, the pppprocomp variable overrides this setting. Default: Enable Range: Disable/Enable If enabled, this configures PPP to use address field compression as defined in RFC1661. For iDEN leave it enabled. If a modem configuration file was downloaded, the pppaddrcomp variable overrides this setting. Set appropriate user name for connecting to the modem when performing PPP authentication. If a modem configuration file was downloaded, the username variable in the file overrides this setting. Set appropriate password for connecting to modem when performing PPP authentication. If a modem configuration file was downloaded, the password variable in the file overrides this setting.

Advanced Link Layer ACE3600 supports several link names on the same port. This feature enables RTU #1 that has one MDLC over IP port, for example ETH1, to communicate directly with RTU #2 that has two MDLC over IP ports, LINE1 and LINE2. In this case, assign LINE1 and LINE2 to RTU #1 MDLC over IP ETH1 port. The following parameters are specific for each link name: TX to failed RTU every Range: 0-30 (0 disables) <0: DISABLE 0-30> Default: 3 Min It specifies a period of time in seconds, after which a failed link will be considered as being back in order, provided the value of the Periodic check of failed RTU parameter is set to Disable. If the Periodic check of failed RTU parameter is enabled, it specifies the period of time in seconds after which the Network layer issues a control frame to check the failed link.

82


Periodic check of failed RTU

Default: Disable The network sends a control frame to check whether the link is still in "failed" status. The frame is issued if the link has been in "failed" status for the period of time specified in the TX to failed RTU every <0:DISABLE 030> Min parameter. Default group IP Range: 000.000.000.000-255.255.255.255 address Identifies Site ID 0 which is used for Group Call on specific link ID. Get host by name Default: Enable. using DNS This parameter enables host name within IP Conversion Table for the specified link name. If set to Disable, host names cannot be used within that link name in IP Conversion Table. The following parameters are common to all Link names configured for this port. MDLC over IP port number

Enable Sync


Range: 1-65535 Default: 2002 This number is common to all RTUs and IP Gateways connected to this link. This number identifies the MDLC. This is a UDP port number and the provider should be consulted. It is important that this number not be in use as specified by the TCP/IP standard RFC0960. Range: Disable/Enable Default: Disable If this parameter is Enabled, this port can send an MDLC Sync to other RTUs, and receive an MDLC sync. If this parameter is Disabled, this port does not send an MDLC Sync, and ignores received sync frames. It can however forward sync words that were initiated from other Link Ids, or from Toolbox. It is recommended to use the NTP protocol instead for time settings. Range: Disable/Enable Default: Enable When enabled, if an RTU’s IP address is changed or obtained from a modem, the RTU will send a message to update its IP Address in all sites. Note: these messages are sent one after the other, and it is not guaranteed they will be delivered and accepted.

83


Enable routing on MDLC over IP port

Range: Disable/Enable Default: Disable When enabled, an RTU or FEP can route back MDLC over IP packets received that destined to a different site ID. When disable, an RTU or FEP ignore packets received which are destined to other sites. This parameter allows two RTUs to communicate via this RTU, is useful if they have dynamic IP address. Note also they need to transmit periodically for their IP address to be updated in its IP Conversion Table.

Modem configuration timeout (Sec)

Range: 40-255 sec Default: 40 The period of time the network will wait for successful configuration of the modem upon power up of modem or RTU. If within this period, the modem configuration does not complete, RTU marks the port as Failed, though configuration continues. If configuration fails, the modem may not be properly configured. Configuration status can be checked using the Error Logger and Software Diagnostics (LIN1L Level 0, 101. For more details, see Modem Configuration below.

Disconnect on icmp:netunreach

Range: Disable/Enable Default: Disable If set to Enable, connection to the modem/radio will be terminated by force when getting an icmp:netunreach. This message specifies that the peer site was unreachable because of network problems. Sometimes these problems can be resolved by reconnecting to the modem. For Tetra, it is recommended to leave it set to Disable. Range: 1- 65535 Default: 0 When specifying a timeout in seconds, the RTU monitors the delay from the last time anything was received from the modem (during PPP mode). If this time expires, this means there is a problem with the modem connection. The RTU will disconnect and reconnect to the modem. If 0, this parameter ignored.


84


Does modem support abort sequence

Ignore CD

Registration life time

Range: YES/NO Default: NO With Tetra radios such as MTM700, no abort sequence is supported. Abort sequence is a +++ string sent with a 1 second delay before and after, causing the modem to move into command mode. Specifying this parameter as NO will expedite connection to Tetra radio. Range: Never, Always, When connect Default: Never. When connecting to the modem, its CD is constantly being polled, and if inactive, the RTU will reconnect to it. This parameter enables the user to bypass the polling by ignoring CD. Setting this parameter to Always will cause RTU not to check CD at all. Setting it into When connect will ignore CD during the PPP connection phase. When PPP is connected, CD will be polled. Setting this parameter to Never will always check CD. Range: 0 to 65535 seconds Default: 7200 If not 0, this sets an interval in which a connected radio/modem is deregistered and reregistered for packet data. The RTU adds an offset to this number, which is derived from its site ID, so not all radios are restarted and context activated at the same time. If a file was downloaded, this parameter can be overridden using the regLifeTimeout variable.

With Tetra, a paging mechanism to each site (peer) in the IP conversion table has been added to make MDLC over IP more reliable. If the parameters below are not visible, they will have the default values as specified. The parameters are the same as in other variations of MDLC over IP, but their default values were changed to suit Tetra infrastructure. For more information, refer to MDLC over IP Site Paging. Check Alive timeout in seconds

Range: 0-65535 sec Default: 35 sec




Range 0-255 Default: 3

85


Special AT Commands for the Tetra Radio The following AT commands are sent by the RTU when configuring the Tetra radio. They can be overridden/added by specifying the Optional AT command string in the Advanced Physical Layer parameters in the Site Configuration utility. It is recommended to override these defaults by downloading a modem configuration file adopted for the radio, such as MTM700.stm for MTM700. For details, see Modem Configuration File below. AT+IFC=2,2 – Instruct the radio to use hardware flow control. AT+WS45=4 – Instruct the radio to initiate PPP with the RTU when getting the ATD command.

MDLC over Standard Modem To avoid system setup for each modem/radio which supports packet data, a general concept has been introduced for, whereby IP can connect to any modem or radio supporting packet data. A standard modem supporting packet data is a modem which requires an AT command set to configure and PPP to initiate. It can connect to a PC using Microsoft Standard Modem and RAS setup. 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\config directory. •

GPRS G18 modem (G18.stm file)

•

Other standard PPP radios

For information of downloading modem configuration files, see Downloading Modem Configuration Files above. 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.

86


MDLC over Standard Modem Setup The general steps of the MDLC over Standard modem Setup are identical to the MDLC over IP Setup. If a modem configuration file is used, this too must be downloaded to the RTU port.

RTU Site Configuration In the Site Configuration, set up either PI1/PI2 or SI1/SI2 as RS232, Async, and select PPP for Standard Modem: RS232, Async, PPP, Standard Modem

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.

Link Parameters for PI1/PI2 or SI1/SI2 Data Speed

Range: 1200 – 115200 Default: 9600

Advanced Physical Layer The values of these parameters are identical to other variations of MDLC over IP as described above.

Advanced Link Layer The values of these parameters are identical to other variations of MDLC over IP as described above. Check Alive timeout in seconds






Special AT Commands for Standard Modem The following AT commands are sent by the RTU when configuring the Standard modem. They can be overridden/added by specifying the Optional AT command string in the Advanced Physical Layer parameters in the Site Configuration utility. It is recommended to override these defaults by downloading a modem configuration file adopted for the radio, such as G18.stm for GPRS. For details, see Modem Configuration File below. 87


AT+IFC=2,2 – Instruct the radio/modem to use hardware flow control. AT&C1 – Instruct the radio/modem to activate CD in online mode. 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.

88


MDLC over GPRS An RTU can be connected to GPRS through a LAN or through a radio. An IP Gateway or an RTU with an Ethernet port can be connected to the LAN. An RTU which 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 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 Gateway

RTU RSlink1

g18 GPRS Packet Data modem

GPRS infrastructure

LINE 1

g18 GPRS Packet Data modem STS

RS-232

g18 GPRS Packet Data modem RTU-B

RTU-A

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).

89


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.

MDLC over GPRS Setup Configuring an RTU to operate over GPRS is the same as configuring MDLC over IP for the Standard modem connection. If a modem configuration file is used (e.g. G18.stm), this too must be downloaded to the appropriate RTU port. 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: <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, set up either PI1/PI2 or SI1/SI2 as RS232, Async, PPP. Select Standard Modem: 90


RS232, Async, PPP, Standard Modem

The Advanced parameters are the same as described above for MDLC over Standard Modem.

MDLC over ASTRO IV&D With SCADA systems, ACE3600 RTUs can be connected to an ASTRO IV&D radio. The ASTRO infrastructure (6.4 or higher) and radio must support integrated voice and data (named IV&D). This is relevant to Motorola subscriber data radios such as the XTL5000 mobile. 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.

91


SCADA Central Ethernet Customer Enterprise Network

LINE 1 RS-232

IP Gateway

STS

ASTRO IV&D infrastructure

GGSN PDR

Base Station

RNG

LINE 1

RS-232

XTL5000 Radio

XTL5000 Radio

RTU-A

RTU-B

STS

92


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.

RTU Site Configuration In the Site Configuration, set up either PI1/PI2 or SI1/SI2 as: RS232, Async, PPP, ASTRO IV&D

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.

93


Link Parameters for PI1/PI2 or SI1/SI2 Link name:

Data Speed

Range: LINE 1-LINE 29. Default: LINE 1 All RTUs and IP Gateways use the same line. Range: 1200 - 57600 Default: 19200

If the RTU needs to log into the infrastructure/radio using a user name via PPP connection, specify the following parameters. User name

Password

SNMP agent port number

SNMP trap port number

Packet data status name

Default routing IP address IP network mask

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. 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. Range: 0-65535 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. Range: 0-65535 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. Default: .1.3.6.1.4.1.161.3.6.30.2.1.1.1. 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. The default gateway of the RTU. This value should remain 000.000.000.000. The subnet mask assigned by to the radio. This value should remain 000.000.000.000.

94



Range: 1-65535 Default: 2002 This number is common to all RTUs and IP Gateways connected to the link. This number identifies the MDLC. This is a UDP port number and the provider should be consulted. It is important that this number not be in use as specified by the TCP/IP standard RFC0960.

Advanced Physical Layer The values of these parameters are identical to other variations of MDLC over IP as described above. Optional AT command string RTS always ON Number of configuration attempts to reset radio/modem


This additional AT string can be used to enhance the modem just before the modem is returned to online mode after configuration. The RTU powers the radio off by unsetting this signal. By default, it is On. Default: 3. Range: 0 to 255. If the RTU fails to context active the radio, it restarts it using AT commands. This parameter determines how many failed attempts to connect (context activate) the radio must occur before restarting the radio. If a modem configuration file was downloaded, the n_failstoreset variable overrides this setting. Default: 7 seconds. Range: 0 to 255 seconds. Specify how long to wait after restarting radio as above before attempting to configure and register it. If a modem configuration file was downloaded, the SetRtsTimeout variable overrides this setting.

95


PPP echo send interval [sec]

PPP echo send max retries.



Default: 10 Range: 0 to 255. If not 0 it determines the time interval to poll the radio over PPP. If no reply is received within max retries, it will declare the cable as disconnected, and start to connect with the radio again. This parameter is needed because ASTRO IV&D radios do not have DCD. If a modem configuration file was downloaded, the pppechosendinterval variable overrides this setting. Default: 3 Range: 0 to 255. If not 0 it determines the number of retries to poll the radio if no reply is received. If no response is received after max retries, the data cable to the radio is regarded as disconnected. This parameter is needed because ASTRO IV&D radios do not have DCD. If a modem configuration file was downloaded, the pppechosendmaxretry variable overrides this setting. Default: Enable Range: Disable/Enable If enabled this configures PPP to use protocol field compression as defined in RFC1661. For ASTRO IV&D, leave it disabled. If a modem configuration file was downloaded, the pppprocomp variable overrides this setting. Default: Disable Range: Disable/Enable If enabled this configures PPP to use address field compression as defined in RFC1661. For ASTRO IV&D, leave it enabled. If a modem configuration file was downloaded, the pppaddrcomp variable overrides this setting.

96


Advanced Link Layer Disconnect on icmp:netunreach

Does modem support abort sequence


Ignore CD

Range: Disable/Enable Default: Disable If set to Enable, the connection to the radio will be terminated by force when getting an icmp:netunreach. This message specifies that the peer site was unreachable because of network problems. Sometimes these problems can be resolved by reconnecting to the modem. For ASTRO IV&D it is recommended to leave it set to Disable. If a modem configuration file was downloaded, the DisconctIcmpNet variable overrides this setting. Range: YES/NO Default: YES Specify YES if the modem supports an abort sequence, a +++ string sent with a 1 second delay before and after, causing the modem to move into command mode. For ASTRO IV&D radios, this parameter should be set to YES. If a modem configuration file was downloaded, the AbortSeqExist variable overrides this setting. Range: 1- 65535 Default: 0 When specifying a timeout in seconds, the RTU monitors the delay from the last time anything was received from the modem (during PPP mode). If this time expires, there is a problem with the radio context activation. The RTU will disconnect and context activate the radio. If a modem configuration file was downloaded, the DisconctRxIdleTime variable overrides this setting. Range: Never, Always, When connect Default: Always. ASTRO IV&D radios do not provide DCD signal when connected, therefore this parameter should Always ignore CD. If a modem configuration file was downloaded, the IgnoreCD variable overrides this setting.

97


Registration life time


Range: 0 – 65535 Default: 0 This parameter is useful with infrastructure that requires periodic restart of radio. If 0, periodic restart of radio is disabled (but can be done via application). If not 0, it specifies how long the RTU keeps the radio context activated before restarting, and then context activates it again. The RTU adds an offset to this number, which is derived from its site ID, so not all radios are restarted and context activated at the same time. If a file was downloaded, this parameter can be overridden using the regLifeTimeout variable. Range: Disable/Enable Default: Enable When enabled, once a radio get context activated, the RTU send a message to update its IP Address in all sites. Note: these messages are sent one after the other, and it is not guaranteed they will be delivered and accepted.

The RTU connected to the radio uses the MDLC paging mechanism as with Tetra and iDEN. An MDLC paging mechanism to each site (peer) in IP conversion table makes MDLC over IP more reliable. For the IP Gateway and IP Interface connected on the CEN, if these parameters are not visible, they take their default values as 0, and issue no MDLC paging from the CEN. For more information, refer to MDLC over IP Site Paging. Check Alive timeout in seconds






The following parameters affect the way the RTU context activates the radio and monitors it via SNMP protocol. The ASTRO IV&D setup requires an SNMP component to be configured in order for the radio to context activate (register for data). This is configured in the radio using the CPS tool and in the RTU using STS. Context activate radio

Range: Disable/Enable Default: Enable When enabled, context activate the radio via SNMP, and monitor it according to the below parameters.

98


Radio context activation timeout

Get radio status sample time

SNMP socket timeout

Range: 0-255 sec Default: 30 sec This parameter is relevant if Context activate radio is set to Enable. It determines how long to wait for a radio to be context activated. If the timeout expires, the RTU will reconfigure the radio, and restart it if needed. Range 0-255 sec Default: 10 sec This parameter is relevant if Context activate radio is set to Enable. Once the radio is context activated, the RTU will monitor it periodically to see that it is still context activated. This parameter determines how frequently to do check this. Range: 0-255 sec. Default: 10 sec. This parameter is relevant if Context activate radio is set to Enable. The RTU sets a radio’s context activate variable and monitors it via an SNMP socket. This parameter determines how long to wait for a response from the radio, before declaring it as failed. If failed, RTU will reconfigure the radio, and restart it if needed.

Special AT Commands for ASTRO IV&D The following AT commands are sent by the RTU when configuring the ASTRO IV&D radio. They can be overridden/added by specifying the Optional AT command string in the Advanced Physical Layer parameters in the Site Configuration utility. A modem configuration file such as XTL5000.stm for mobile XTL5000 radio can be downloaded to override these defaults. AT#RESET – Instruct the radio to restart. AT – Check that the radio is connected and can be configured. ATH – Disconnect the radio from PPP mode after issuing an abort sequence (+++). ATE0V1 – Set no echo and AT command verbose return codes. AT&K3 – Instruct the radio to use hardware flow control. ATD – Connect the radio in PPP mode.

99


MDLC over MotoTrbo With SCADA systems, ACE3600 RTUs and ACE IP Gateways can be connected to a MotoTrbo radio in digital mode, to use MDLC over IP communication via the MotoTrbo digital mode radio system. The MotoTrbo radio is connected directly (not via hub) to one of the RTU/IPGW’s USB host ports. The port connection between the RTU and the radio is a USB host running IP over RNDIS (Microsoft Remote NDIS protocol version Revision 1.1.) Note: The DHCP protocol is also used for obtaining IP address from the radio. This IP address is internal within the USB connection and does not reflect the actual IP address over the air. Up to two MotoTrbo radios can be connected to one unit (RTU or IP Gateway), as long as they are assigned different IP addresses on a different network mask (e.g. 199.19.10.1 and 199.19.11.1) using the CPS. (NOTE: Only one MotoTrbo radio can be connected to any given power supply.) The STS (PC) may be connected directly (locally) to the radio via a single unit, by specifying the radio’s IP address in the Communication Setup. For example, if radio’s network ID is 12 and the radio ID is 10, specify 13.0.0.10 (13 because to access the unit specify the network ID 12 plus 1). The STS should not be connected remotely to other units connected to the MotoTrbo radio network due to performance issues. The user may perform STS operations such as loggers, download, hardware test, monitor, and set/ get date & time (effective data throughput ~800 bps). MDLC time synchronization is not recommended, because of the long delays added by the radio/repeater. Network Time Protocol (NTP) provides better time synchronization accuracy, ~200 ms accuracy with a repeater. By default, MDLC time synchronization is disabled, but it can be enabled in the port’s advanced physical parameters. In single repeater or IP site connect topologies, the unit attached to the MotoTrbo radio may initiate or receive MDLC group calls over a single link ID. For example: If a radio network group ID=225, set site ID 0 to IP address 225.0.0.1. Note: Adding this feature requires changes in the CPS of the radio (adding a digital Call to the contact list, and referring to it in the RX Group list; marking the ‘forward to PC’ field in the network folder.) If using MDLC time synchronization, it is important to set a group IP address. For example if using Digital Call ID 1, set it to 225.0.0.1 in the STS.) Note: There may be delays, depending on the topology used. IMPORTANT: For sending group calls, the default group IP address can be configured in the advanced link layer of the HU1/HU2 port tab, or in the IP conversion table for site ID 0 and the proper link ID. This is the only way a setcall can be delivered by MotoTRBO in digital mode. Each RTU or FEP has a fixed IP address. This address is derived from the radio to which it is connected. For example: If the radio ID=1 and the network ID=12, the address is 13.0.0.1. The network mask is always 255.255.255.0. The unit learns the local radio IP address dynamically. For example: If 199.19.10.1 is configured in the radio CPS, this is not the real IP address transmitted over the air. The real IP is 13.0.0.1.

100


Unlike other infrastructures such as iDEN and TETRA, the radio’s 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.

MDLC over MotoTrbo Setup The general steps of the MDLC over MotoTrbo Setup are like those of MDLC over IP Setup. There is no need to download a modem configuration file, just an IP conversion table. For details on the connection, see the MDLC over IP/Remote NDIS Host Connection section above. Note: If two radios are connected to the unit (RTU or IP Gateway), the radios’ IP addresses should be set to two different network mask addresses. For example: Set the first radio to 199.19.10.1 and the second radio to 199.19.11.1.

RTU Site Configuration In the Site Configuration, set up either USB port (HU1 or HU2) for MotoTrbo: USB Host, Async, Remote NDIS Host, MotoTrbo

The USB port configuration is similar to that of other IP ports. The following advanced physical parameters are specific to MDLC over MotoTrbo. Number of input buffers <1-1024>

[64]:

The number of buffers for the USB and RNDIS layers to be used for receiving data (the number of clusters used within the Enhanced Network Device END during reception from that port.) Reducing this parameter may cause reception loss in extreme cases where the system is busy. When increasing it, allocate more memory in advance. Note: If more than one MotoTrbo radio is connected, the first (HU1) port sets the number of input buffers, and the setting for the second port is ignored. Number of output buffers <1-1024>

[64]:

The number of buffers for the USB and RNDIS layers to be used when transmitting data. During transmission to the MotoTrbo port, the IP frames sent are queued one at a time. A single request transaction is issued, one at a time, per each frame sent to the USB. Once a transmission has completed, i.e. has been acked by the radio USB device, another one is sent. (This does not mean that it was transmitted over the air, just pending transmission in the radio.) This parameter determines the maximal number of frames pending transmission that may be stored in the RTU. Reducing it may cause transmission failures, while increasing it requires more memory for storage space. KeepAlive timeout period (seconds) <0-65535>

[5]:

The interval at which the RTU polls the MotoTrbo radio to check the connectivity status. The polling is done using the RNDIS and DHCP protocols. If the connection with the radio is disconnected, the RTU reinitiates the connection to the radio (and the RNDIS and DHCP protocols) in order to transmit and receive IP via the USB port. 101


If the interval is set to 0, polling the radio is disabled (not recommended.) Decreasing this parameter to a non zero value, will cause more frequent polls. Increasing the interval will reduce the number of polls, but will also delay the disconnect detection and the re-initiation of the radio connection. Regardless of this parameter setting, the RTU monitors the USB connection status passively.

MDLC over Null Modem The RTU can connect to any device using direct cable over PPP. This is supported for MDLC over IP and can connect, for example, to a Terminal Server over PPP. 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.

MDLC over Null Modem Setup The general steps of the MDLC over Null modem Setup are identical to the MDLC over IP Setup. Although no real modem exists, a modem configuration file can be attached to a port and downloaded to override the default settings of the port.

RTU Site Configuration In the Site Configuration, set up either PI1/PI2 or SI1/SI2 as RS232, Async, and select PPP for Null Modem: RS232, Async, PPP, Null Modem

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.

Modem Configuration File For ACE3600 RTUs, a modem configuration file can be downloaded to the following PPP ports (packet data modems):

102


RS232, Async, PPP, iDEN RS232, Async, PPP, Tetra RS232, Async, PPP, Standard Modem RS232, Async, PPP, Null Modem RS232, Async, PPP, ASTRO6 IV&D

For ACE3600 RTUs, a modem configuration file can be downloaded to the following dialup (circuit data) port: RS232, Async, External dialup

(Note for dialup: You must use the RS232E+ adaptor.) The modem configuration file (also called standard modem configuration file) is an ASCII file with sections in which exact AT commands can be specified for connecting to a modem. Some “environment variables” can be set as well to define the exact behavior of the port control function (dealing with connecting the modem and checking that it remains connected.) This file also contains special sections for diagnosing the modem using AT commands via STS SW Diagnostics. Since several circuit data modems can be connected to RTU, the user should specify for which port the file is being downloaded: i.e. port PI1, PI2, SI1 or SI2. This is done in the Downloader utility. Note that for now, only a single packet data modem/radio can be connected to an RTU. The same configuration file can be used with different sections for circuit data programming and packet data programming. Since dialup port (circuit data) and PPP ports (packet data) configure the modem differently, separate sections have been set for each type: The ConfigureCD section configures a dialup port, and ConfigurePD configures a PPP port. For dialup ports only, a dedicated section called ChkVld is used to check that the modem is operational and able to receive calls. To enable the user diagnose the modem status, Diag0 to Diag7 sections have been allocated. These sections are invoked when using the SW Diagnostics level 223 or above. Level 223 is set for running Diag0, level 224 for Diag1, etc. This diagnostic disconnects the modem temporarily while diagnosing the modem. For that reason, the dialup port will refuse to perform this operation while in the middle of a call and returns an error. MDLC Over IP enables this feature by disconnecting PPP temporarily and turning it back on once the diagnostics are complete.

Modem Configuration File Example The following is an example of a modem configuration file for the G18 modem (G18.stm): [Initialize] $FileVersion= 1.10 update. $WaitForOk= 2000 $WaitForDial= 30000 $WaitForDiag= 15000 $DTEIPAddr= 0.0.0.0

; Version of file 1.x must stay the same. ; Advised to increase revision on each ; Wait time for OK in milliseconds ; wait time for Dialup in milliseconds ; Wait for diag timeout in milliseconds ; IP Address of DTE (MOSCAD). 103


; ; ; ; ; ;

$GtwyIPAddr= 0.0.0.0 $DTESubnetMask= 0.0.0.0

Set to 0 in order to obtain from radio. IP Address default gateway. Set to 0 in order to obtain from radio. Subnet Mask Set to 0 in order to obtain from radio. PPP user name if authentication is

$Username= needed. $Password= ; PPP password if authentication is needed. $AbortSeqExist= 1 ; 1 - Modem support abort Sequence $IgnoreCD= 2 ; 0 - Never / 1 - Always / 2 - Ignore CD when connecting $DisconctIcmpNet= 0 ; 1 - Disconnect modem when getting ICMP:Net Unreach $DisconctRxIdleTime= 900 ; Disconnect on idle timeout in seconds (15 min) ; 0 - never disconnect if inactive, $UnsetRtsTimeout= 2000 ; Wait time before restart the modem (unset RTS). $SetRtsTimeout= 4000 ; Wait time after restart the modem (setting RTS). $ModemAddress= 0 ; Modem/radio address (string) $ModemVersion= 0 ; Modem/radio version (string) $ModemName= Motorola GSM g18 ; Modem/radio type for diagnotic purposes $ModemRSSI= -; Modem/radio RSSI $ToggleRtsCommand= 0 ; 1 - Toggle RTS (modem's DTR) at SetCommandMode $pppechosendinterval= 0 ; PPP Echo send interval in milliseconds. $pppechosendmaxretry= 0 ; PPP Echo send max retries. $pppprocomp= 1 ; 1- Enable PPP protocol compression $pppaddrcomp= 1 ; 1- Enable PPP address compression $pppmaxmtu= 1500 ; PPP Max MTU frame size $pppauthpro= 0 ; PPP Authentication Protocol 0xc023/0xc223 $pppasynctl= 0 ; PPP Async Control Char Map $n_failstoreset= 2 ; Number of configuration failures to reset modem $max_failedtime= 120000 ; If failed to configure for 120 seconds errorlog ; Applicable for IP and not for dialup modems $WaitAfterDial= 2000 ; 2 seconds to wait after dialup to another modem ; Relevant for dialup only. $RetryModemConfig= 0 ; Set to 1 if need to retry modem configuration ; Relevant for dialup only. $RegLifeTime= 7200 ; Registration timeout in seconds [Prereset] ; Does nothing except for unsetting RTS ; (powers modem's plastic box off) [Postreset] ; Does nothing except for setting RTS ; (powers modem's plastic box on) [SetCommandMode] <><><1> <+++><><1> [HangupCD] <> <4> <2>

; Wait 1 second. ; Wait 1 second. ; ; ; ; ;

**For MDLC over Dialup** Send ATH\r. Expect no reply. Send ATH\r; Expect NO CARRIER reply within 4 seconds. Send AT\r; Expect OK reply within 104


; 2 seconds. [HangupPD] ; **For MDLC over IP** <0x7e0xff0x030xc00x210x050x020x000x040x590x280x7e><><2> ; Send LCP ; Terminate Request <> ; Send ATH\r. Expect no reply. <> ; Send ATH\r; Expect no reply. <2> ; Send AT\r; Expect OK reply within ; 2 seconds. [VerifyParms] <$ModemVersion> ; Send ATI3\r; store reply in $ModemVersion <$ModemAddress>; Send AT+CIMI\r; store reply in $ModemAddress <$ModemRSSi> ; Send AT+CSQ\r; store reply in $ModemRSSi [ConfigureCD] <><><5> <><2>

; ; ; ; ; ; ;

**For MDLC over Dialup** Wait 5 seconds after modem recovers. Restore to factory configuration. Configuration string Set modem in SMS text mode. Save in profile 0. After powerup, load profile 0

[ConfigurePD] <2>

; **For MDLC over IP** ; Send AT\r; expect OK reply within 2 ; seconds. <2> ; Configuration within 2 seconds. <><2> ; Set modem in SMS text mode <5> ; Attach to GPRS; expect OK reply within 5 ; seconds. <+CGPRS: 1><2> ; Check GPRS coverage. ; Expect +CGPRS: 1 reply. <4> ; Define APN - PDP contact (profile) [DialPD] ; **For MDLC over IP** <40> ; Set Modem in PPP mode by dialing ATD*99## [GoOnLine]

; **For MDLC over Dialup** ; Go online from command mode (circuit data).

[ChkVld] ; **For MDLC over Dialup** ; Send AT\r; expect OK. <+CREG:000 001> ; Send AT+CREG?\r; expect +CREG:000 001 ; reply. [Diag0] <$Diag> <$Diag> <$Diag> <$Diag> <$Diag>

; ; ; : : :

This is level 223. Modem version : Modem IMSI : Modem pin number: Hardware Version: Manufacturer :

[Diag1] <$Diag> <$Diag> <$Diag> <$Diag> <$Diag>

; ; ; ; ; ;

This is level 224. Signal quality : Registration : Is GPRS Attached: Is GPRS Covered : Is in Text mode :

[Diag2] <$Diag><2>

; This is level 225.

105


Modem Configuration File Sections Several modem configuration files are included as part of the STS installation. The structure of the modem configuration file is comprised of the following sections. Section Name

PPP port

Dialup

Invoked when

Initialize

Starting to configure modem or when a new file was downloaded. Hanging up PPP.

Starting to configure modem or when a new file was downloaded. Hanging up call. Hanging up call.

Starting to configure modem.

SetCommandMode HangupCD HangupPD

VerifyParms

Hanging up PPP.

Configure modem in PPP Step [1].

Configuring modem made at power restart or when check validity fails. Step [1] of 3.

ConfigureCD

ConfigurePD


VerifyIPParms

Optional step before DialPD.

DialPD


Diag0

SW Diagnostics of LIN1L level 223.

Checking modem able to receive calls. Made when modem was idle for specified number of seconds. SW Diagnostics of LIN1D level 223.

Diag1

SW Diagnostics of LIN1L level 224. SW Diagnostics of LIN1L level 225.

SW Diagnostics of LIN1D level 224. SW Diagnostics of LIN1D level 225.

ChkVld

Diag2

106

Dialup only. PPP only. Hanging up PPP is invoked when need to diagnose modem, or when start to configure it. PPP only. Modem is configured when it is detected that PPP is not connected or when RTU is restarted or when a new file is downloaded. Dialup Only.

PPP only. Modem is configured when it is detected that PPP is not connected. PPP only. If need to read modem IP Address via AT commands such as iM1000. PPP only. Modem is configured when it is detected that PPP is not connected. Dialup only. If fails, modem is reconfigured.

LIN1L and LIN1D is the name of the port with LINE1 link ID. This section is optional. This section is optional. This section is optional.


Section Name

PPP port

Dialup

Invoked when

Diag3

SW Diagnostics of LIN1L level 226. SW Diagnostics of LIN1L level 227. SW Diagnostics of LIN1L level 228. SW Diagnostics of LIN1L level 229. SW Diagnostics of LIN1L level 230.

SW Diagnostics of LIN1D level 226. SW Diagnostics of LIN1D level 227. SW Diagnostics of LIN1D level 228. SW Diagnostics of LIN1D level 229. SW Diagnostics of LIN1D level 230.

This section is optional.

Section Name

PPP port

Dialup

Invoked when

Prereset

Issue reset AT command to radio/modem when applicable. Some modems can be powered off and on this way. Check if modem connected after restarted.

Issue reset AT command to radio/modem when applicable. Some modems can be powered off and on this way. Check if modem connected after restarted.

First time configuring modem, or after failed to configure several times consecutively.

Diag4 Diag5 Diag6 Diag7

Postreset

This section is optional. This section is optional. This section is optional. This section is optional.

After restarting modem and waiting for it to recover.

MDLC over IP Modem Configuration The MDLC over IP port runs certain sections of the modem configuration file to configure the modem and set it in PPP. This is done using a packet data modem connection such as Standard Modem or Tetra. During this time, the port is not considered eligible for transmission, and any transmissions are held pending for a predetermined time in a queue. This time is determined in the site configuration in the Advanced Link Layer Modem Configuration Timeout parameter. 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. 107


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. 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: 6. VerifyParms section. Verifies modem identity. This is not a mandatory section. 7. ConfigurePD section. 8. DialPD dialup modem and place it in PPP mode. This cause modem to register within infrastructure. Once modem has been configured it is now monitored to maintain that connection. Its PPP connection is monitored as well as its DCD signal, which shows that it is active. This indicates that the modem is indeed registered and able to receive and transmit IP over the air. Some modems do not have DCD. A variable named IgnoreCD can be set to 2 (IgnoreAlways) so the DCD will not be polled. It is recommended to consult with technical support before using such a modem/radio. PPP based modems initiate PPP once you dial into it. Connecting PPP involves actually registering the modem within the infrastructure. This may take several seconds or up to a minute. During this time, the port is not considered eligible for transmission and any transmissions are still held pending in queue. Once PPP is connected, the frames can be transmitted. The modem is configured in the following situations: 1. When it is detected that the modem is not PPP connected, or its DCD has dropped; 2. When the RTU experiences a power restart (with or without battery); 108


3. When the RTU restarts because of a new configuration; 4. When downloading a new configuration file; 5. When diagnosing the modem using modem configuration file; levels 223 and above are used for that purpose. In the last three cases, the modem is disconnected and is not configured immediately. When diagnosing using a modem configuration file, the modem is interrogated using AT commands, and its responses are queued within the MDLC over IP port. Once all responses received, MDLC over IP port reconfigures the modem as specified above. Note that if it is done remotely, e.g. over a GPRS network, the diagnostic response may take 30 seconds or more. The user should set the modem configuration timeout to be long enough so that the response does not get lost. A 30 seconds timeout is a typical delay but it may need to be extended to 60 seconds.

MDLC over Dialup Modem Configuration The user can configure the modem from the RTU using the MDLC over Dialup port. In previous systems, the user had to configure the modem externally (e.g. PC terminal) and then save those parameters in the modem. A config modem string can be defined in the Physical Layer to configure the modem. The modem configuration file enables the user includes the config modem string and other AT commands. If no modem configuration file exists, the config modem string will be used. If both exist, the modem configuration file will be used. 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: 3. VerifyParms section. Verifies modem identity. This is not a mandatory section. 109


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.

How to Test a Modem for Dialup Prior to using an external modem, emulate an external terminal using a PC and any standard communication program, and set its parameters as follows: • • • •

9600 bps (for example) 8 bits no parity 1 stop bit

Enter the modem telephone numbers into the site phonebook. If you are using an external modem, set its configuration according to the following list. Action

Command

Disable off-line echoing Enable audio messages Disable quiet mode (The status codes are sent to the terminal.) Enable all codes Enable carrier detect when a connection is established.

ATE0 ATV1 ATQ0 ATX4 AT&C1

You may enter the commands in one string, ATE0V1Q0X4&CI&W, where &W implies saving the above parameters for the next power-up. It is also possible to configure the modem from the RTU over a dialup port. A modem configuration file is used to send the appropriate AT commands to the modem. For more information, see the MDLC over Dialup Modem Configuration. When several RTUs are connected to the PSTN (Public Switching Telephone Network), as illustrated below, several configurations are viable as described in the examples that follow.

110


RTU 2 MODEM AT PORT SI2

MODEM AT PORT SI1

MODEM AT PORT SI2

PSTN

RTU 1

MODEM AT PORT SI1

RTU 3

MODEM AT PORT SI2 MODEM AT PORT SI2

MODEM AT PORT SI1

RTU 4

RTU 5

Note that in the illustrated configurations, as in all the connections over the PSTN, there is only one link ID. It is the responsibility of the software to decide which line to dial. When two lines are available, the Port SI1 line has priority.

1. To communicate between RTU 1 and RTU 2: • Configure RTU 1 port as external modem. • Update the RTU 2 telephone number. • 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. 2. To communicate between RTU 1 and RTU 4: • Configure RTU 1 port as external modem. • Update the two RTU 4 telephone numbers. • 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.

111


3. To communicate between RTU 4, RTU 5, and RTU 3 simultaneously: • Configure RTU 4 Port SI1 and SI2 as external modem. • 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.

Diagnosing the Modem over the MDLC over Dialup Port MDLC over Dialup can also diagnose a modem using its modem configuration file. This is done by connecting the STS and running the SW Diagnostics on Device LIN1D Level 223 or above. If the appropriate DiagX section (e.g. Diag0 for 223, Diag1 for 224) does not exist in the modem configuration file, no action is taken. If it exists, the modem is interrogated and its responses are displayed in SW Diagnostics. 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.)

Modem Configuration File Variables The variables listed below control the way modem is configured by the RTU. 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. There are three types of variables: •

INT – Four byte integer variables representing time or Boolean (true or false) values. Boolean values are 0 for false and 1 for true. 112


•

IP Address – Four digit IP addresses in the form of xxx.xxx.xxx.xxx where xxx ranges from 0 to 255.

•

String – Any character string up to 30 characters.

Usually a variable is set manually in the [initialize] section as explained above. For example: $WaitForOk= 2000

sets the WaitForOK variable to 2000. A variable can also be set/overridden from the modem. For example: <$ModemAddress>

sends the AT+CIMI command to the modem and sets the ModemAddress variable to the modem address in the response. All variable values can be viewed using the SW Diagnostics level 221 for LIN1L (or LIN1D in dialup port). LIN1 stands for link ID LINE1. If a different link ID is used, such as LINE7 the device would be LIN7L or LIN7D. The FileVersion variable is used to identify the modem configuration file version. FileVersion=xx.yy, where xx is the file version and yy is the file revision. When the file is downloaded, the RTU verifies that it supports its version. The file version (xx) should not be changed unless stated. The revision number (yy) is used to keep track of your changes to the file. It has no meaning to the modem but it is recommended that it be increased each time the file is changed. For the first release of this feature, the file version should be set to 1.0. Variable name

Meaning

Type

Comment

FileVersion

File version and revision: version.rev (e.g. 1.0)

STRING

Used for both PPP and dialup.

The following variables are used when programming the modem. Some of them are PPPspecific. Some are common to both MDLC Over IP and MDLC Over Dialup. Variable name

Meaning

Type

Comment

WaitForOk

Default timeout in millisecs to wait for modem reply

INT

Common to both MDLC Over IP and MDLC Over Dialup

WaitForDial

Default timeout in millisecs to wait for connection to succeed when dialing

INT

MDLC over Dialup only

WaitForDiag

Timeout in millisecs used when diagnosing modem; has no meaning for now

INT

Common to both

DTEIpAddr

IP Address of RTU

IP Address

MDLC Over IP only

113


Variable name

Meaning

Type

Comment

DCEIpAddr

IP Address of modem

IP Address

MDLC Over IP only

GTWYIpAddr

IP Address of gateway

IP Address

MDLC Over IP only

DTESubnetMask

Subnet mask of modem

IP Address

MDLC Over IP only

DTEPrefixlen

Number of 1s (most significant bits) in subnet mask, e.g. 16: 255.255.0.0

INT

MDLC Over IP only (iDEN especially)

UserName

Username to be used when authenticating PPP using PAP or CHAP

STRING

Password

Password to be used when authenticating PPP using PAP or CHAP

STRING

AbortSeqExist

1 if modem supports abort sequence. Abort sequence is +++ string sent to modem in order to change it from data to command mode.

INT

MDLC Over IP only Also found in Site configuration user section. MDLC Over IP only Also found in Site configuration user section. Common for both

Whether or not to ignore CD. 0 – never ignore, 1 – ignore always, 2 – ignore during dial.

INT

DisconctIcmpNet

Disconnect modem when getting ICMP:Destunreach

INT

MDLC Over IP only Also found in Site configuration Advanced Link.

DisconctRxIdleTime

Disconnect modem when not getting anything for RxIdleTime in seconds. 0 means it will never be disconnected.

INT

MDLC Over IP only Also found in Site configuration Advanced Link.

SetRTSTimeout

Time to wait after setting RTS in milliseconds and powering on the modem where applicable (e.g. G18 and XTS2500 ASTRO IV&D radio)

INT

Common to both

IgnoreCD

114

For MDLC over IP, also found in Site configuration Advanced Link. Common to both For MDLC over IP, also found in Site configuration Advanced Link.


Variable name

Meaning

Type

Comment

UnsetRTSTimeout

Time to wait after unsetting RTS in milliseconds and powering on the modem where applicable (e.g. G18 and XTS2500 ASTRO IV&D radio)

INT

Common to both

ToggleRTSCommand

1 if need to toggle RTS when setting modem in command mode. 0 RTS will not be toggled when setting modem in command mode.

INT

Common to both

The following variables are for diagnostics only. Variable name

Meaning

Type

Comment

ModemName

Name of modem

STRING

Common to both

ModemAddress

Address of modem such as MAC address

STRING

Common to both

ModemVersion

Version of modem

STRING

Common to both

ModemRSSI

RSSI of modem

STRING

Common to both

The following additional PPP variables are available in the STS configuration. If these variables were set in a file, their value set in that file overrides those settings.

Variable name

Meaning

Type

Comment

Pppechosendinterval

PPP Echo send interval in milliseconds. By default it is 0. To support modems that do not provide DCD input to RTU, RTU will poll modem using PPP in order to check if it is connected.

INT

MDLC over IP only.

Pppechosendmaxretry

PPP Echo send max retries. If modem does not reply within that limit, it is detected as disconnected. RTU will try to reconnect it via PPP.

INT

MDLC over IP only

115


Pppprocomp

PPP protocol compression. This parameter can be 0 or 1. By default it is 1 which specifies that the RTU use this option. For those CDMA modems which do not support that feature, it should be set to 0.

INT

MDLC over IP

Pppaddrcomp

PPP address compression. This parameter can be 0 or 1. By default it is 1 which specifies that the RTU use this option. For those CDMA modems which do not support that feature, it should be set to 0.

INT

MDLC over IP

PPPmaxmtu

PPP maximal frame in bytes. 1500 is standard.

INT

MDLC over IP

Pppauthpro

PPP authentication protocol. If 0, it will be negotiated with the modem via PPP protocol. Two other authentication protocol supported are 0xc023 (PAP), and 0xc223 (CHAP). The user can force the RTU to ask for another protocol, but as a PPP client this is usually 0.

INT

MDLC over IP

PPPasynctl

PPP Async Control Character Map. Usually set to 0.

INT

MDLC over IP

116


The following variables are not PPP related: Variable name

Meaning

Type

Comment

N_failstoreset

Number of configuration failures to reset modem. This parameter is interpreted differently in MDLC over IP than in dialup.

INT

MDLC over IP MDLC over Dialup

In MDLC over IP, when failing to connect to the modem several times, it determines after how many failures to restart the modem. If 0, it will never be restarted. In dialup, the modem is restarted immediately after detecting it has failed. If this parameter is 0, it will not be restarted. Max_failedtime

This parameter is in milliseconds.

INT

MDLC over IP

If the RTU failed to connect with modem for 120 seconds, it will notify the error logger. WaitAfterDial

Time to wait in milliseconds after dialing to another modem and getting connected. This is to enable the other modem enough time to connect. By default this parameter is set to 2000 (2 seconds).

INT

MDLC over Dialup

RetryModemConfig

If set to 1, instruct the RTU to keep retrying to configure modem in case it was disconnected and failed configuration.

INT

MDLC over Dialup only

By default it is 0: The RTU will try to configure modem only once, and if it fails will not retry.

The following variable is for the [DiagX] section such as Diag0. It instructs the RTU to route the modem response into the SW Diagnostics. Variable name

Meaning

Type

Diag

Last modem response when executing Diag section.

STRING

117

Comment


Modem Configuration File Command Syntax The format of the AT commands in the modem configuration file is as follows: If no is specified, no command will be issued. Note that empty brackets <> must be used if no command is to be issued. If no 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 is specified, the RTU will wait $WaitForOkTimeout seconds for the modem to respond. If the received response does not match the , 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 is automatically appended with \r (0x0D Hex), unless is empty. In that case, ‘0x0D’ should be appended explicitly in the command. Each AT command response is automatically prefixed and appended with \n\r (0x0A and 0x0D) by the modem. When specifying the , there is no need to specify them. can also be an environment variable. For example: <$ModemAddress>

will issue the AT+CIMI Command and put its response in ModemAddress variable. Multiple responses can be expected by specifying them inside the braces (of expected response). For example: <(OK)(NO CARRIER)>

will expect either OK or NO CARRIER response. <+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:

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> Terminate Request

; LCP

This string is a binary string comprised of the bytes 7e in hex, ff in hex, 03 in hex etc. It is used for terminating a PPP session. 118


IP Conversion Tables The IP conversion table is created in the ACE3600 STS using the IP Conversion Table Manager. Note that unlike the network configuration, there is no default, and any IP conversion tables must be created manually. The IP conversion table maps sites in the system (site ID+link ID) to IP addresses or host names. Each site ID/link ID pair can have one unique entry in the table, though an IP address can appear in more than one row. A site ID of 0 is reserved for a group call. In RS232 PPP and Ethernet DHCP, the IP address is read from the network once it is connected to the RTU. In Astro IV&D, this is not the real IP address set by the infrastructure; rather, it is a dummy address configured in the radio via the CPS Mobile Computer IP address which is (by default) 192.168.128.2. In the IP conversion table do not specify this address, but the actual IP address assigned by the infrastructure operator. Note: The IP address displayed by the SW Diagnostics LIN1L level 0 is the dummy address and should not be used in the IP conversion table. The ACE3600 IP conversion table format includes a link ID column which allows more than one port in the same site to be connected to LAN or to PPP. Any legacy MOSCAD RTU or IP Gateway in the network must defined using its own Toolbox IP Conversion Table utility. Control Center CEN LAN FEP 100

LINE 1

FEP

10.5.1.xx

LINE 2

Packet Data Network

192.5.1.xx

Subscriber Radio 2

Subscriber Radio 1 PPP/RS-232

LINE 1

LINE 1

PPP/RS-232

PEI RTU-B

PEI RTU-A LINE 2

LINE 2

LAN 155.9.1.xx

In the example above, two sets of IP conversion tables should be created and the FEP’s Table should be assigned to the RTUs: FEPs Table: Site ID

Link ID

IP Address or Host name

119


100

LINE1

10.5.1.160

100

LINE2

155.9.1.17

The RTUs Table should be assigned to the FEP: Site ID

Link ID


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

PI1 www.mysite.com 155.9.16.102 155.9.16.103 155.9.193.240 * marks the

recently used DNS server 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: Site ID

Link ID


100

LINE1

FEP1.moto.com

100

LINE2

FEP2.moto.com

In this example, LINE2 is Static LAN so the user needs to set the DNS servers of LINE2 network in the LINE2 port configuration of RTU #1 and RTU #2. LINE1 is PPP, so there is no need to set these servers – they are learned from the network automatically. 120


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.

MDLC over IP Connection Verification Once the setup for the desired MDLC over IP variation is completed and the necessary files (site configuration and IP Conversion table and perhaps modem configuration file) have been downloaded to the RTU, the connection should be verified. 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. 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.

121

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. The following attributes are defined for the firewall. Activate firewall?

[Disable]:

Whether the site’s firewall should be activated. Max size of ICMP packet <0-65535>

[100]:

The MAX size of ICMP Echo (ping) allowed. A ping packet with a bigger size will be ignored, no response will be sent back. Firewall address list

The list of IP addresses allowed to pass through this firewall. If no IP address is defined, then all addresses are allowed. To add or remove addresses from the list, click on Address List. To append a line, click on Append Line. To remove a line, click on Remove Line. To save the list, click on OK. If the firewall is active, all UDP/ TCP ports will be blocked (e.g. telnet, http) except for the following: • DHCP port • DNS port • MDLC port (UDP 2002) • NTP port • MODBUS port (TCP 502) • Expansion TCP connectivity and data ports (configurable, by default 57001, and 57002) • Expansion UDP discovery port (57001, not user configurable) • Timer event (UDP 57003)

122

Firewall

Enable communication with remote STS

[Enable]

Whether the RTU enables communication from a remote RTU (Enable) or only from the local STS (Disable). Avoid gratuitous ARP

[Enable]

When this parameter is set to Enable, gratuitous ARP transmissions are not sent. When this parameter is set to Disable, gratuitous ARP transmissions are sent.

Firewall with I/O Expansion In a system with I/O expansion, an enabled firewall could potentially block communication from expansion frames to the main frame. To enable communication from expansion frames to a main frame with enabled firewall, either: •

Manually enter the IP addresses of the expansion frames and main frame (as described in I/O Expansion Configuration above.) OR

•

Make sure that no address ranges are defined in the firewall Address List (default) and the firewall will allow all IP communication.

When you save the site configuration in a system with I/O expansion, the warning message below will be displayed under the following circumstances: •

At least one expansion is defined in the site configuration OR Automatic I/O Recognition is enabled (i.e. the ‘Enable auto I/O modules recognition at startup,’ field is checked in the site’s I/O tab.)

•

The firewall is enabled;

•

An address range has been defined in the firewall Address List;

•

The firewall Address List does not include the full range of IP addresses (for thirteen expansion frames and the main frame.)

This message prompts you to define the IP addresses of expansion frames in the firewall Address List.

123

Firewall

If you want the STS to add the missing IP addresses (based on the address calculation described in I/O Expansion Configuration above), check the first option and click OK. All addresses will be added, even if not all thirteen expansion frames are defined. The IP address of the main CPU will be added as well. (0.0.0.0-0.0.0.13 for the default IP address) If less than thirteen expansion frames are defined for the system, the range can then be modified manually to include only defined frames. If you want to add the desired address range(s) manually, check the second option and click OK. Add the IP Address of the main CPU to the list (as described in I/O Expansion Configuration above) as well as all configured frames. If the range in the IP address list is less than thirteen addresses (i.e. the system contains less than thirteen expansion frames), be sure to check ‘Do not ask me again’ or you will continue to receive the message window whenever you save the site configuration. To cancel the operation, click on Cancel. The save operation will be aborted. If the expansion frames are subsequently deleted from the site configuration but the firewall Address List still contains the IP address range of the expansion frames, the following warning message will be displayed (when saving the configuration) to remind the user to delete these addresses from the list. Click on OK and then remove the address ranges from Advanced -> Firewall -> Address List.)

124

Firewall

If you choose to leave these IP addresses in the list, check ‘Do not show this message again’ and click on OK. Otherwise, you will continue to receive this message. For more on IP addresses and configuration of expansion frames, see the I/O Expansion Configuration section above.

125

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.

Time Adjustment and Synchronization MDLC time synchronization of the RTU clock can be performed locally or remotely, using MDLC protocol over a variety of communication media, including conventional radio, RS485, and RS232. Synchronization is accurate to 1 millisecond+0.5 (very low delay. With IP media, this feature can be enabled, but because its accuracy/delay is unpredictable it is not recommended. NTP, the recommended method of obtaining the time over IP media (PPP or Ethernet), allows accuracy of 1 to 100 milliseconds depending on the media.

126


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 RTUs in different time zones, and better accuracy than the MOSCAD MDLC legacy synchronization. Note that by default, the ACE3600 uses MOSCAD MDLC legacy synchronization (to support IP Gateway and MOSCAD RTUs) which does not include the time zone and password features. Note: An extended time synchronization of two RTUs, where only one is configured for time zone, will proceed as if both RTUs are in the same time zone. The RTU clock can be synchronized during runtime using a number of methods. Before synchronizing the clock, make sure that the appropriate parameters have been configured properly. (See Time Parameter Configuration below.) User Time Control Actions •

STS Date & Time utility – From the STS, the user sets the RTU date/time to the 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.

127


- 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 monitoring a database table, see the Application Programmer chapter of the ACE3600 STS User Guide. System Time Control Actions •

GPS Connection – An RTU which is connected to a GPS receiver continuously polls the GPS time and synchronizes itself. Because the clock source is reliable, this RTU can be used to synchronize the rest of the system. See the Global Positioning System (GPS) section below.

•

NTP Connection – An RTU which is connected to an NTP server continuously polls the NTP server(s). Because the clock source is reliable, this RTU can be used to synchronize the rest of the system. The accuracy of NTP time depends on the link to the NTP server. It can be 1 millisecond in a LAN where the NTP server reside on the same network, and up to 100 milliseconds if using wireless media such as GPRS or TETRA. See the NTP Clock Synchronization section below.

Notes: 1. When obtaining the time from system time control actions (GPS receiver and/or NTP server) and the time is valid, the ClockValid system flag in the Reserved flags system table is set to 1. When this flag is set, all user time control actions (e.g. Date & Time command, Sync command) are ignored. 2. An RTU or FEP connected to a GPS receiver and/or NTP server, can synchronize other RTUs either from the ladder application Sync command, or using STS Sync operation. Note that for IP media this is disabled by default, and is not recommended, but for non-IP media such as radio or RS485 it is valid. 3. PC hosts, NTP servers, and GPS receivers operate on UTC time (GMT time zone). If it is necessary to us the local time– set this time zone in the ‘Timezone offset in minutes’ advanced parameter in the STS site configuration. If the synchronizing RTU is in a different time zone than the RTU being synchronized and uses extended time sync,, the system will adjust the time accordingly; the receiving RTU will add the time zone of the sender to the global time (GMT) and use this. If only one of the two RTUs involved is configured for time zone support, the synchronization will proceed as if both sites are in the same time zone. Note: A legacy MOSCAD RTUs is treated as an RTU which is not configured for time zone support.

Time Parameter Configuration Configuration of the RTU’s clock and time characteristics and functions is done during system initialization. Compatibility issues may arise in hybrid systems which include 128


ACE3600 RTUs and legacy MOSCAD RTUs. The behavior of the RTU in such situations is determined by the settings in the relevant STS site configuration parameters.

Time Synchronization The following Time Synchronization parameters are found in the Advanced tab of the STS site configuration. Time sync method

[Legacy Sync]:

This parameter defines the method to be used when sending time synchronization. In a system with legacy RTUs, the sync method should be Legacy Sync. Extended Sync – RTU sends sync protocol frames containing time zone and password, with nanosecond resolution. (1 millisecond accuracy over synchronous media (radio) and over asynchronous RTU to RTU media.) Note: The RTU checks the password in extended sync frames and authenticates sync messages before updating the clock. If it does not match it will be rejected. See SW Diagnostics Device TIMESYN level 10 for statistics of received/ignored sync frames. Legacy Sync – For synchronizing legacy MOSCAD RTUs. No time zone or password, with milliseconds resolution. Assumes sending RTU is in the same time zone. (5 millisecond accuracy) This is the default in ACE3600. What to do with received legacy sync messages?

[Don’t Ignore legacy sync messages]:

This parameter determines the behavior of the RTU when it receives a legacy sync frame. It has no meaning when receiving an extended MDLC sync. The valid values are: Ignore legacy sync messages – Do not update the clock when legacy sync messages are received. Don’t ignore legacy sync messages – Update the clock when legacy sync messages are received. This is the default, so ACE3600 can be synced from a MOSCAD or from another ACE3600.

Time Zone The following Time Zone parameters are found in the Advanced tab of the STS site configuration. Time zone learning mode

[No time zone]:

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 129


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. Time zone offset in minutes <(-720)-720>

[0]:

The time zone offset from GMT, counting east. This parameter is relevant if the ‘Time zone learning mode’ parameter is set to “User Configured.”

Port Advanced Link Parameters The following parameter is found in the Advanced Link parameters for MDLC over IP (PPP or Ethernet) ports (serial onboard or plug-in) in the Ports tab of the STS site configuration. Enable sync

[Disable]:

For PPP, 10/100 BT, USB Host connections. This parameter enables or disables synchronization over IP. It must be enabled in both the sending and receiving unit in order to synchronize. Note: Because the delay is unpredictable, enabling this parameter is not recommended. Use NTP instead where possible. Enable reply to time synchronization

[Disable]:

For PPP, 10/100 BT and USB connections. Enables/disables reply to time synchronization over IP.

Daylight Saving Dates Table The Daylight Saving Dates table is used to define the start and end dates for 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. 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. 130


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.

131


Time Synchronization Diagnostics Synchronization diagnostics can be retrieved from the ACE3600 RTU using the STS SW Diagnostics & Logger device TIMESYN. Level 0 provides MDLC time synchronization parameters. Level 10, 11 provide MDLC time synchronization statistics. For details, see the TIMESYN device in the ACE3600 Software Diagnostic Output and Error Messages manual. 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.

NTP Clock Synchronization The Network Time Protocol (NTP) can be used as an external clock source to synchronize the ACE3600 RTU over IP with one or more NTP servers. 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. 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.

132


Figure 1 NTP architecture As the above figure shows, time is distributed from an NTP subnet of servers. Each server comprises a stratum, which designate its location in terms of hops to the UTC source. The stratum 1 is the most accurate server of which all servers should be synchronized to. Up to 15 stratum levels may exist. Stratum 16 means server unreachable. 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 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.

133


NTP Setup 1. In MDLC over IP port (either RS232 PPP or 10/100 BaseT) select up to three NTP servers. In some systems, where NTP servers are not available, specify another RTU/FEP ACE3600. The IP address of NTP server can be either numeric such as 10.17.1.161 or host name such as www.ntp.comm.mot.com . The later format can be used only if DNS servers were set or learned from the network. If you have several MDLC over IP port, you can set-up several NTP servers, but make sure the above tree structure is preserved. 2. Connect this server to a GPS or to another NTP server(s). Another option is not to configure it with any GPS and NTP servers. 3. Set time zone. In the above first two cases you also need to set time zone in advanced parameters, so it operates in local time. In the last case, where using a stand alone ACE3600 as a server (no GPS and no NTP configured) there is no need to set a time zone. 4. Make sure all servers are in sync. If you configure your primary sever as connected to GPS, make sure it is able to receive satellites. Check GPS level 1 and NTP level 1 to see it is synchronized, otherwise it will not be regarded as a valid server. If your primary server is not configured for GPS and to any other NTP server, it is OK, but make sure you have only one like that or sync it periodically to avoid clock drift from other servers (for example by time sync it every few minutes). The NTP advanced parameters explained in ACE3600 STS User Guide, Appendix A Site configuration parameters. The most important parameters are shown below: Max sync offset in msec <0-500>

[0]:

The maximum permitted offset of the RTU clock from its NTP server(s). If the offset exceeds this amount, the NTP servers will be polled frequently to correct the offset, possibly causing a heavy communication load. When set to 0, the offset is not checked. It is recommended to leave this parameter set to 0. Minimal poll interval in sec <1-64>

[4]:

The minimal interval in seconds between polling the NTP server(s). NTP works by polling its servers. This is the minimal time in seconds that is polled. After a poll and sync, the interval to the next poll is multiplied until reaching the ‘Maximal poll interval in seconds’. (See the next parameter.) Note: When contact with the server is lost, the minimal poll interval is used to resync as fast as possible. Maximal poll interval in seconds <1-1311072>

[1000]:

The maximal interval in seconds between polling the NTP server(s). See ‘Minimal poll interval in sec’ above. 1000 seconds is ~17 minutes. Transmit BURST when poll

[Yes]:

134


If this parameter is set to YES (default) when polling 8 messages are sent instead of one every 2 seconds apart in order to sync as fast as possible. If NO only a single poll message is sent. Time sync lost before declare ‘no sync’ in sec

[120]:

The number of seconds to wait before declaring ‘no sync’ state after being in sync. When no reply is received from the NTP server(s), or when getting invalid replies ‘no sync’ is declared, and the ClockValid in the Reserved Flags database system table is set to 0. 120 by default means it takes 2 minutes to indicate that. Notify error logger when losing sync

[Yes]:

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.

NTP Diagnostics and Verification To verify that NTP is functioning properly, use the STS SW Diagnostics, the Error Logger and the ladder application database: 1. Check STS SW Diagnostic device NTP level 1. If it is operative, it will shows “clock synchronized” and the current clock offset. 2. An error is logged if synchronization is lost from all NTP servers. 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. To check the NTP servers status: 1. Check STS SW Diagnostic device NTP level 2. It shows the list of NTP servers. Sun Oct 29 10:33:07 2006

SITE: 2

LINK: LINE 2

DEVICE: NTP

LEVEL: 2

Fail

Prev

Next

Peer address

port assoc Strat test

Flags poll

poll

delay

offset

disper.

maxrxtime

------------

---- ----- ----- ----

----

-----

------

-------

-------

---------

10.5.1.160 *10.5.1.161

ETH1 30780 16 ETH1 30781 10

0000H 0000H

----

0301H 617 0341H 505

135

409 518

0.000 1.125

0.000 -0.729

0.000 0.071

0.000 3.396


The first column shows the status of the NTP server. 10.5.1.160 is unreachable because it has no symbol, and 10.5.1.161 is reachable ‘*’ marks it as a system peer. Both are polled via ETH1. The stratum of the system peer is 10 meaning this is an ACE3600 which is not connected to any NTP server or GPS receiver, otherwise it would have much smaller stratum. The Prev and Next Poll designate in seconds when last time polled and when will next poll occur. The delay is in milliseconds says 1.125 milliseconds delay to server. The offset is also in milliseconds –0.729 milliseconds. The dispersion says how stable is the clock, the less it is the better the clock. maxrxtime is for internal use. Another method of testing NTP is using ntpq . 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.

Global Positioning System (GPS) The ACE3600 system can use a GPS receiver precise time measurement application for synchronization purposes, to synchronize the RTU with other SCADA systems. 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. One of the recommended GPS receivers 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. Another recommended GPS receiver is the NMEA 0183 Garmin GPS 16 HVS. For details on connecting to the GPS receiver, see Appendix A in this manual.

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 for the Oncore M12+T receiver and Garmin GPS 16 HVS respectively.

136


Link Parameters for PI1/PI2 or SI1/SI2 Time period to get data from GPS (sec) <8-60>

[10]:

This field defines the interval between two time updates from the GPS receiver. . Note that a drift of 30 ppm per day in ACE3600 RTU is 1.78 milliseconds per minute. Setting the clock every 10 seconds will prevent this drift. The GPS advanced parameters explained in ACE3600 STS User Guide, Appendix A Site configuration parameters. The most important parameters are shown below:

Advanced Link Layer Offset in milliseconds

Default: 0 Range: 0- 86400000 The field defines the time offset to add for GPS time in the Universal Time Coordinate (UTC). The range is 0-86400000 msec. This parameter is for testing purpose and should be left as 0. For adding local time offset set it in time zone section of advanced parameters.

Powerup with factory defaults

Default: Disable Range: Disable/Enable If Enabled the GPS receiver will power up with defaults from factory, taking it longer to obtain time.

Set GPS in position Hold (Timing only)

Default: Enable Range: Disable/Enable This parameter should be enabled for M12+T timing receiver and disabled for non- timing receivers. If enabled, in order to perform precise timing, the GPS receiver position is determined and then the receiver is put into Position-Hold mode where the receiver no longer solves for position. With the position known, time is the only remaining unknown. When in this mode, the GPS receiver only requires one satellite to accurately determine time. If multiple satellites are tracked, then the time solution is based on an average of the satellite measurements.

137


Advanced Physical Layer RTS always ON

Default: No Range: Yes/No. This parameter should be left as NO since RTS has no meaning in GPS.

Polarity of PPS input signal

Default: Rising Edge Range: Rising Edge (Active Low)/Falling Edge (Active High) This parameter determines the PPS (Pulse per second) polarity in DCD input. For M12+T it is set as LOW.

After setting the GPS parameters and downloading the configuration to the RTU, the unit starts updating its time accordingly. You may use the Get Site Time & Date utility to verify the RTU time.

GPS Diagnostics and Verification The system flag, ClockValid, is included in the Reserved Flags (system) table. A value of ‘1’ indicates that a GPS receiver is connected to the RTU and the receiver is updated from the satellite. When ClockValid=1 the RTU updates its time from the GPS, and ignores any synchronization words received from other systems, from the Site Time & Date utility, or through the ladder diagram language. ClockValid=0 indicates that the GPS receiver is not connected to the RTU, or that the GPS is connected and a satellite connection failure has occurred. Following system power-on, it takes up to 15 minutes for the GPS receiver to start reading the satellite time. 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.

NTP Advanced Parameters for GPS The NTP advanced parameters affect the GPS. In ACE3600 the GPS is regarded as an NTP clock source over RS232. The defaults are suitable for GPS, yet the following 138


parameters enable warning messages when losing time synchronization (when ClockValid is 0.): Time sync lost before declare ‘no sync’ in sec

Default: 120 The number of seconds to wait before declaring ‘no sync’, when no reply is received from the NTP server after a poll. During this wait period, polling is increased. If ‘no sync’ is declared, the ClockValid flag in the Reserved Flags database system table is set to Nr (see the next parameter.) If GPS is configured, ‘no sync’ occurs when no valid satellite status is received for this period of time.

Notify error logger when losing sync

Default: Yes Range: Yes/No Whether notification should be sent to the Error Logger when declaring ‘no sync’. By default this parameter is "Yes", meaning a message is logged into error logger when getting into "no sync" state after being in sync. If ‘no sync’ occurs again, no message is logged until the user retrieves SW Diagnostics device NTP level 10.

Clock Synchronization of I/O Expansion Frames In systems with I/O expansion, clock synchronization of the expansion modules is controlled by the main CPU. For more information, see the Time & Sequencing Synchronization of I/O Expansion in the ACE3600 I/Os section above.

139

ACE IP Gateway The ACE IP Gateway for SCADA systems (CPU 4600) is an advanced unit based on Freescale’s Power PC II MPC8270 microprocessor. It provides the SCADA software with access to the ACE3600 and MOSCAD systems, based on the seven layers of the MDLC protocol, in order to exchange data with the RTUs. A typical example of the ACE IP Gateway (IPGW) is shown in the figure below; a SCADA control center is connected via the ACE IP Gateway to RTUs on a radio link, to RTUs on an RS485 link and to RTUs on an IP in the ACE3600 system. The MDLC network communicates via the ACE IP Gateway with any SCADA computer which supports TCP/IP (UNIX, Windows XP, etc.)

The SCADA control center, which includes workstations and a SCADA computer, exchanges data with the ACE3600/MOSCAD system via the ACE IP Gateway, which serves as a Gateway from the TCP/IP world to the MDLC world. There are many SCADA packages which already have the Gateway Interface driver implemented, some as direct access to the ACE IP Gateway, and some as OPC server.

140

ACE IP Gateway

The ACE IP Gateway uses the TCP/IP LAN Protocol for exchanging data application messages with the SCADA software. The ACE IP Gateway API (Application Programming Interface) allows SCADA driver developers to quickly and easily build the ACE IP Gateway Interface (driver), which serves as a communication interface with the MDLC world. Data exchange between the SCADA (client) and the ACE IP Gateway (server) is carried out using TCP/IP “peer -to-peer” communication over LAN. The ACE IP Gateway can support multiple connections that are initiated from multiple SCADA computers. The implementation of the ACE IP Gateway interface in the SCADA software allows the SCADA to perform the following operations: •

Poll an RTU in order to get data and COS (Change-of-State) events from the RTU tables.

•

Send commands to the RTU and download parameters to its local process.

•

Send commands via broadcasts to any required group of RTUs.

•

Download parameters (set-points) to the RTU local process.

•

Receive spontaneous reports (by contention) from RTUs (both burst and event transmission).

•

Receive time-tagged events logged in the RTUs (1 msec resolution).

•

Adjust the RTUs’ clocks (1 sec resolution).

•

Synchronize the RTUs’ clocks.

•

Support redundant ACE IP Gateway configuration by setting the Gateway mode to be Primary/Secondary).

•

Retrieve Gateway status.

•

Retrieve RTU links status.

•

Update RTU links in the site table.

•

Retrieve software diagnostics from ACE IP Gateway itself.

For a detailed description of the interface, please refer to the ACE IP Gateway API manual.

ACE IP Gateway System Overview SCADA System The complete control system is comprised of the SCADA control center (or centers) communicating with ACE3600/MOSCAD RTUs over various communication links, such as: 141

ACE IP Gateway • • • • • • • • • •

Conventional radio Analog trunked radio ASTRO IV&D radio TETRA radio Motorola MotoTrbo radio (digital mode) Data radio Cellular modems Dial-up lines IP network (LAN, WAN) Mixed media networks

The communication system is used for transmitting alarms, status and telemetry, calculated data diagnostics and error logging information from the RTUs to the central facility computer and vice versa. It is also used for downloading, monitoring and debugging the application program at the sites. The system may be relatively simple, comprising several RTUs and a single control center, or a more complicated hierarchical system, where several sub-control-centers communicate with lower, parallel and higher hierarchies. The RTUs may also communicate with each other and/or with any other hierarchy in the system. The figure below depicts a system with more than one SCADA control center, an ACE IP Gateway, and RTUs which are connected to a variety of media including RS232, RS485, IP and radio link. Note that the ACE3600 STS can be connected to the ACE IP Gateway or to any ACE3600 RTU over RS232 or over Ethernet.

142

ACE IP Gateway

The ACE3600/MOSCAD system uses the MDLC protocol, based on the seven layers of the OSI model published by ISO, and adapted for SCADA communications. It provides network support, multiple logical channels per physical port, allowing each RTU to simultaneously run several communication sessions, such as data exchange, on-line monitoring, diagnostics, etc. The ACE3600 system is supplied with a Software Tools Suite (STS) package that runs on a PC running Windows XP or Windows Vista. All RTU functions such as configuration, database and process definition, downloading, monitoring, hardware and software diagnostics, etc. are defined using the STS. The ACE3600 STS can communicate with the Gateway via RS232 or IP. The STS may be connected either locally to an RTU or via the MDLC port of the ACE IP Gateway to any RTU in the system. All programming and monitoring functions can be performed either locally or remotely. (The Gateway can serve as an MDLC router between the ACE3600 STS and RTUs.) Note: When the ACE3600 STS is connected locally to one of the RTUs in the system, it can service any other RTU in the system via the MDLC communication network. Multiple SCADA control centers can simultaneously perform multiple sessions with the ACE IP Gateway in order to send commands and polling requests to the RTUs and to receive data and contention reports from the ACE3600 RTUs. All this can be done via a single physical Ethernet Gateway static LAN port. By default the Gateway port is ETH1, but any Ethernet port may be used. 143

ACE IP Gateway

In a SCADA system, ACE3600 RTUs and ACE IP Gateways can use IP (Internet Protocol) technology to interface to advanced radio infrastructure (e.g. digital ASTRO IV&D and TETRA systems) and to standard private IP networks. MDLC and IP networks can be integrated in the same system, as MDLC networking properties are preserved. MDLC applications need not be modified as the lower layers of the protocol support IP. For details on these various interfaces, see MDLC over IP Communication above.

SCADA Interface Client-Server environment The SCADA application for the ACE IP Gateway is based on a client-server approach. The Gateway application acts as a server while the SCADA Interface acts as a client. In such a relationship, the SCADA Interface must establish the connections with the Gateway needed for communicating with the ACE3600 RTUs. After the connections have been established, the SCADA Interface can send data, commands, and polling requests to the field RTUs. It can also establish a special connection that enables receipt of data transmissions initiated by the field RTUs (so called burst/RTU event data, contention data or Change-Of-State [COS] messages). Note: The ACE IP Gateway checks its connections to the SCADA from its end, to make sure they are alive. At the same time, the SCADA must check from its end that its connections to the ACE IP Gateway are alive.

Channels and Channel types The SCADA Interface must establish at least one connection toward the Gateway server. These connections are called channels and are used to transfer messages from the SCADA center toward both the Gateway and the RTUs in the field. The client application can open different types of channels to best serve its SCADA Interface process. The two basic channel types are: •

Regular

•

Spontaneous

A Regular channel enables asynchronous sending/receiving of data and requests. It uses a mailbox mechanism for mapping the request messages to their replies. A Spontaneous channel allows receiving burst data (Spontaneous COS messages) and RTU events - i.e. transmissions initiated by the field RTUs. This feature almost eliminates the need for the SCADA application to poll data since every change in one of the telemetry field variables can immediately be transmitted to the SCADA application.

ACE3600/MOSCAD System - RTU Definitions To make the ACE3600/MOSCAD field system definition transparent to the SCADA client application and to correctly parse the data received from the ACE3600/MOSCAD system, 144

ACE IP Gateway

the API builds an internal data structure defining the types and numbers of the field RTUs. To do so, it uses two external system definition files (in ASCII format). This automatic system definition done by the API routines hides the field system structure from the SCADA application and eliminates the need for any application modifications when working with different ACE3600/MOSCAD systems. Moreover, new RTUs can be added to the system at run time using the appropriate API routine.

Primary/Secondary Gateway Modes The ACE IP Gateway supports a redundant configuration. There are two modes of operation: Primary and Secondary. If there is a single standalone ACE IP Gateway, then it starts up as Primary. If the system configuration includes redundant Gateways, then both start up as Secondary and the SCADA must determine which one will be set to function as Primary. At any other time, the SCADA can change the mode of operation by calling the appropriate API set mode routine. The API also supplies a routine for checking the current mode of operation. This functionality of the ACE IP Gateway provides redundant gateway operation, which minimizes the risk of communication failure. For more information, see ACE IP Gateway Redundancy below.

Communicating with the ACE IP Gateway Once a channel has been established with the Gateway, the SCADA interface can issue requests to the Gateway. The request categories are Send routines, Receive routines, Data Analysis routines and Management routines. Typical API sequence calls are the following: Connect

/* Establish Connection to Gateway. */

Poll

/* Send a polling request. */

Receive

/* Receive MDLC communication (answer) buffer. */

Troubleshooting The ACE IP Gateway communication can be diagnosed using the STS Software Diagnostics and Loggers tool. For detailed information, see the ACE3600 Software Diagnostics and Error Messages manual.

Health Check Mechanism General The ACE IP Gateway system includes a Health Check mechanism which manages the MDLC connectivity to the sites. Associated with each site are two links, through which the site can be reached. A background MDLC “ping” mechanism in both the Gateway and the ACE3600 units constantly verifies which links are available. If both links are failed, no communication will be forwarded from the SCADA to that failed RTU.

145

ACE IP Gateway

The Health Check mechanism uses the site table as the basis for its operations. Health Check reduces communication overhead (retries and delays) by identifying which links are available and routing frames to operational links.

MDLC Infrastructure MDLC provides a frame-sequence service for the Health Check mechanism. Specifically, a dedicated channel is allocated for this activity at both the RTU and the Gateway. All Health Check messages are transmitted and received through this channel. Being a framesequence channel, the Health Check MDLC channel is both reliable and a low-resource consumer at the same time. MDLC provides a framework for the two entities (the Gateway and RTUs) to maintain this mechanism but the actual protocol (data, timing, policy, etc.) is determined in the RTU/Gateway firmware.

Mechanism In the ACE IP Gateway, the Health Check mechanism relies on the MDLC infrastructure denoted above. When activated, it takes the dedicated Health Check channel provided by MDLC and uses the site table as a source for all sites to be managed. For each site, the Health Check performs the following process: At a predefined interval, the Gateway sends a “ping” frame to each site, one through each of the site’s links. It then expects to receive a response frame for each “ping” sent. A “ping” arriving from a certain site through a certain link, will set the communication status of that link to OK. A site that possesses at least one link in OK status is considered reachable. This process constantly monitors the status of each site’s links and provides the ACE IP Gateway with an updated communication status of all sites in the field. The Health Check protocol uses a minimal amount of system resources (length of data, and time.) On the RTU side, the Health Check mechanism relies on the MDLC infrastructure described above. It operates in slave mode. When a “ping” frame is received by the RTU, the RTU Health Check mechanism replies with an echo of that frame. The RTU transmits a response back to the ACE IP Gateway over the same link. Unless it is “pinged”, the RTU Health Check mechanism will not initiate any communication.

Disabled Health Check When Health Check is disabled in the ACE IP Gateway, the Gateway assumes that all sites registered in the site table are reachable. When Health Check is disabled in the RTU, the RTU MDLC stack will not allow any incoming Health Check messages. Instead, an automatic response indicating that Health Check application is blocked will be communicated back to the originator of an incoming “ping” frame. The ACE IP Gateway Health Check assumes the link is OK if such a response is received. However, indications received from the Health Check mechanism may not be accurate, since the specific path through which the response packet arrived cannot be determined. 146

ACE IP Gateway

Health Check Setup The ACE IP Gateway site table lists all the sites which the Health Check is requested to monitor. Each site is associated with two links, one primary and one secondary. Each link is given a time parameter – Link validity interval. For each link, the Health Check mechanism uses the Link validity interval to calculate the time base for the “ping” mechanism operation. This parameter also determines the maximum wait time for a response at the ACE IP Gateway before declaring a link in fail status. The default value for the Link validity interval for ACE3600 RTUs is 000.05.00 (5 minutes in HHH.MM.SS format.) Each site table entry also includes a Retries value (the number of attempts to be made to communicate with a non-responding RTU) and a Timeout value (the time to wait between communication retries.) When defining primary and secondary links, note the following: •

If the primary and secondary link IDs are identical (e.g. both RADIO 1), the Health Check mechanism will assume the site possesses only one link and thus will not “ping” the same site twice. The Secondary link validity value will be ignored.

•

If the primary and secondary link IDs are not identical (e.g. RADIO 1 and LINE 1), the two paths to the site (one through each link ID) should not overlap in any part of the route. If two different paths to the same RTU do overlap in part of the route, the indications received from the Health Check mechanism regarding each link ID may not be accurate.

IMPORTANT: If the primary and secondary link IDs are not identical (e.g. RADIO 1 and LINE 1), the Primary link validity cannot be set to 000.00.00. 000.00.00 means that the link will always be considered as valid, so: 1) This link will not be monitored by the Health Check mechanism. 2) The Secondary link will never be checked. (Therefore the STS will not permit the user to set the primary link validity to be 000.00.00 and the secondary link validity to another value.) In this case, since the primary link is considered to be valid, the SCADA will always try to transmit to the site over this link. If it transmits frequently, a ‘bottleneck’ situation may arise in the ACE IP Gateway due to lack of communication resources. Therefore, the Primary Link validity should only be set to 000.00.00 in two cases: 1) An RTU that is defined in the project for future use but is not connected yet; 2) A non-node RTU with a single link access on which the Health Check will not be performed. In this case, it is responsibility of the SCADA to identify and handle communication failures to the site. Note: Unlike the legacy IP Gateway which ‘translated’ the 000.00.00 zero value to the default value of five seconds, in the ACE IP Gateway, the Primary link validity of 000.00.00 is indeed 0 seconds, and effectively disables Health Check for the link. 147

ACE IP Gateway

For more information on configuring the links and the link validity intervals, see the Managing Site Tables section in the ACE3600 STS User Guide. Once the site table is set up, the ACE IP Gateway Health Check mechanism is activated in ACE3600 STS site view in Advanced -> Frame Sequence Layer -> Health-check (application) support parameter for the ACE IP Gateway and for all relevant RTUs. The parameter is enabled by default. For more details on the ‘Health-check (application) support’ parameter, see Appendix A: Site Configuration Parameters in the ACE3600 STS User Guide.

Health Check Diagnostics The following software diagnostics are relevant to the Health Check mechanism: •

The STBLA software device diagnoses the active site table in the RTU.

•

The HELTHCH software device diagnoses the Health Check mechanism itself

•

The LNKHNDL software device diagnoses the site links.

For details on the software diagnostics, see the relevant sections in the ACE3600 STS Software Diagnostics and Error Messages manual.

ACE IP Gateway Site Configuration To configure the ACE IP Gateway in the ACE3600 STS, follow the procedure below. To configure a redundant ACE IP Gateway, see Redundant ACE IP Gateway Configurations below. 1. In the ACE3600 STS, drag an ACE IP Gateway from the Inventory tab to the system. 2. Click on the new Gateway. In the site view, the Gateway ID is 189 by default, but this can be changed. Make sure to leave the Redundancy Startup mode set to Stand Alone. 3. By default, the ACE IP Gateway ETH1 port (Static LAN) is configured for the SCADA protocol. If you want to use another port, you must remove SCADA support from port ETH1. (The SCADA protocol can only be supported on one port.) To do so, click on the ETH1 in the ports tab, click on the Protocols button, and in the ‘Select Protocols to Support’ dialog, uncheck SCADA. Click OK. 4. In the Ports tab, select another IP port (PI1, PI2). Set the port to 10/100 BT, Static LAN only. (The ACE IP Gateway does not support SCADA protocol on DHCP ports.) Click on the Protocols button, and in the ‘Select Protocols to Support’ dialog, check SCADA. Click OK. 5. Configure the other link parameters (Links, IP address, DNS servers, NTP servers.) 6. Save the configuration. Note: If more than one port is configured for SCADA protocol, the configuration will not be saved. If no port is configured for SCADA protocol, a warning is displayed. 148

ACE IP Gateway

ACE IP Gateway Terminal Server Ports The ACE IP Gateway (CPU 4600) supports a number of on-board and plug-in ports. If more serial ports are required for MDLC communications, external hardware such as a Terminal Server can be added. The Terminal Server, which has an Ethernet port and many RS232 ports, conveys communication traffic from the Ethernet port to the RS232 ports and vice versa. The ACE IP Gateway establishes a connection to the Terminal Server over the LAN and establishes IP sessions for each RS232 port that is utilized for MDLC communication. The connection remains opened even if there is no data to transmit/receive. Every connection is associated with an IP address (of the Terminal Server), a TCP port ID (associated with the specific RS232 port in that specific Terminal Server), the MDLC link ID for the port, and the physical port over which the Gateway will route packets to the Terminal Server. The Gateway is designed to support up to 32 ports connected to one or more Terminal Servers. For more information on adding and configuring ACE IP Gateway Terminal Server ports in the ACE3600 STS, see Customizing the Configuration of a Site in the Operation chapter of the ACE3600 STS User Guide. IP Address = xxx.xxx.xxx.xxx SCADA Computer

ACE IP Gateway

IP Address = yyy.yyy.yyy.yyy

IP Address = zzz.zzz.zzz.zzz

PORT 2008

RTU #1

...

RTU #N

PORT 2008

RTU #1

...

RTU #N

Configuring the Terminal Server to work with ACE IP Gateway Assign an IP address to the Terminal Server, and define each port allocated to MDLC as a SERVICE with a unique TCP port ID. Due to the large variety of terminal server equipment in the world, when setting such a system, the system engineer must determine all other configuration settings.

149

ACE IP Gateway

ACE IP Gateway Redundancy A redundant ACE IP Gateway can be configured to minimize the risk of a SCADA control center single point of failure (lost contact with sites), and to ensure high availability for its applications. Two Gateways are set up with similar configurations. After startup, both will act as secondary Gateways. When the SCADA establishes connections to the Gateways, the SCADA driver designates one of the Gateways as ‘primary’ and the other as ‘secondary’. Only one ACE IP Gateway can be primary at any time. When redundant ACE IP Gateways peers exist, only the primary Gateway will update the network. Note: When the unit is shipped from the factory, it will start up initially (before site configuration download), as a primary Gateway in Standalone mode, even in systems with redundant Gateways. ACE IP Gateway Site ID 10044/1

ACE IP Gateway Site ID 10044/2

Gateway Designation

Startup Mode

Gateway Designation

Startup Mode

When the unit is shipped from the factory:

Primary

Standalone

Primary

Standalone

After initial download of site configuration:

Secondary

Redundant GW1

Secondary

Redundant GW2

After SCADA driver changes the Gateway Redundancy Mode:

Primary

Redundant GW1

Secondary

Redundant GW2

After the 1st ACE IP Gateway becomes unavailable and the SCADA changes the 2nd Gateway to Primary:

Secondary

Redundant GW1

Primary

Redundant GW2

The primary Gateway communicates properly over MDLC communication and over the SCADA channels. There is bi-directional transfer of both SCADA application messages and ACE IP Gateway management messages. The secondary Gateway transfers ACE IP Gateway management messages only. (It does not send or receive any MDLC messages, since it is logically disconnected from the link.) •

The secondary Gateway does not acknowledge any frame received by the MDLC communication (except local connection).

150

ACE IP Gateway

•

The requests queued in the secondary Gateway will return errors once activated. (In most cases this will be immediately. However, in some cases it could take as long as the longest MDLC session timeout defined.)

•

The secondary Gateway disconnects from all the Terminal Server ports defined in the site configuration.

When the primary Gateway becomes unavailable, the secondary (similarly configured) Gateway takes over. To increase the availability of the LAN network, dual Ethernet segments can be used, and each Gateway can be connected to a different segment. When a Gateway is configured for redundancy, it checks each of the channels to the unit. If all the channels to the Gateway are disconnected or unavailable, the Gateway automatically switches to ‘secondary’ mode.

Redundant ACE IP Gateway Configurations There are several possible options for Redundant ACE IP Gateway system configuration: 1. Both ACE IP Gateways are connected to the MOSCAD system over an IP network. Using this configuration, the ACE IP Gateway’s mode change takes effect immediately for requests going from the ACE IP Gateway to the RTUs. The SCADA should initiate a communication to the RTU through the ‘new’ primary ACE IP Gateway in order for the RTU being able to send Bursts to it. 2. Both ACE IP Gateways are connected to the MOSCAD system over the same many-tomany media (i.e. RS485/Radio). In this configuration, when the secondary ACE IP Gateway becomes primary, the ACE IP Gateway’s mode changes take effect immediately. 3. Both ACE IP Gateways are connected to the MOSCAD system over the same Terminal Sessions. In this configuration, the ‘old primary’ ACE IP Gateway must close all of the Terminal Server connections, the terminal server must end its sessions with the ‘old primary’ ACE IP Gateway and then the ‘new primary’ ACE IP Gateway must establish connection with the Terminal server. In this configuration, several minutes may elapse before the ACE IP Gateway’s mode changes take effect.

Site Configuration (Redundant Gateway) To configure a redundant ACE IP Gateway in the ACE3600 STS. 1. In the ACE3600 STS, add an ACE IP Gateway to the system. 2. In the site view, select a Redundancy Startup mode of Redundant GW1 or Redundant GW2. The Site ID (e.g. 10044) will appear as 10044/1. 3. Save the site configuration and download it to the primary ACE IP Gateway. 4. Add another ACE IP Gateway to the system. IMPORTANT: The Site ID of the secondary ACE IP Gateway should identical to the Site ID of the primary ACE IP Gateway. However, the Gateway ID of each ACE IP Gateway should be unique.

151

ACE IP Gateway

5. In the site view, select a Redundancy Startup mode of Redundant GW2. The Site ID (e.g. 10044) will appear as 10044/2. 6. Save the site configuration and download it to the secondary Gateway. Note: In a redundant system, the Gateway that is configured as Redundant GW1 is the one that will affect the overall system network, with respect to its links. Redundant GW2 does not affect the network at all.

152

MDLC Password Change For nonsecured MDLC communication, the system uses the MDLC legacy password which was defined during project creation. This password is downloaded to the RTUs in the site configuration and used for STS-to-RTU and RTU-to-RTU communication. The first time that the MDLC communication driver is invoked from the STS, the user is prompted to confirm the MDLC password. The MDLC driver remains active until it is stopped, even if you close the project. If, for some reason, the STS must communicate with an RTU from a different project which uses a different MDLC legacy password, the MDLC driver must be stopped and restarted. The password can also be overridden temporarily. If the driver is stopped and later reinvoked (i.e. the STS tries to communicate with the RTU) the user is prompted again to confirm the MDLC password. Until STS V17.50, changing the MDLC password for a system involved travelling to each site, erasing the flash and downloading a new configuration with the new password. As of STS V17.50, the MLDC legacy password for an entire project can be changed from the STS. The new password is defined for the communication driver in the STS and then downloaded remotely to all RTUs in the system in the site configuration file. During the change process, the STS tracks the passwords downloaded to each site. The STS automatically identifies when all sites have received the new password and guides the user with comments and automatic driver restart when required. Note: The MDLC password can also be changed in the STS only (e.g. when preparing a project off-line, when creating a new project from a project template, or if you receive a project from a third party and need to change the project password to the one used in your system.) IMPORTANT: To minimize lost communication, changing the system’s MLDC password should be completed as quickly as possible. In large systems, tracking the progress is important to avoid confusion.

MDLC Password Update Mode After the user defines a new MDLC password, the STS goes into MDLC password update mode. In this mode, the STS keeps track of the current password of each RTU in the (Needs Download) icon. project. In the STS, these RTUs are marked with the Next, the user downloads the configuration file with the updated password to each RTU (with the MDLC communication driver using the previous password.) When each RTU restarts after the download, it uses the new password. In the STS, these RTUs are marked (non identical MDLC password) icon until the password change process is with the complete. Note: Downloading to each RTU individual requires careful tracking to avoid confusion. You can download the updated password to all RTUs using the Download All Sites command, but the actual download process may be lengthy in a large system. 153

MDLC Password Change

Finally, when all RTUs are updated, the STS moves to the new password and exits MLDC password update mode. The MDLC driver is restarted to use the new password, and the STS non-identical MDLC password icons are cleared. For detailed instructions on changing the MDLC password, see Changing the MDLC Password in the ACE3600 STS User Guide the Operation chapter. Note: If the MDLC password is changed in the STS only, the STS does not enter MDLC password update mode and the RTU icons are unchanged. To communicate with an updated site during the password change process (e.g. to verify that the download was successful), the STS must temporarily use the new password. The STS identifies the mismatch between the STS and the RTU, and automatically stops and restarts MDLC driver with the new password. When the operation is complete, the MLDC password change process can resume. Again, the STS identifies the mismatch between the STS and the next RTU, and stops and restarts MDLC driver with the previous password. This is possible because the STS keeps track of the current password of each RTU in the project. For detailed instructions on password mismatch, see Changing the MDLC Password in the ACE3600 STS User Guide the Operation chapter. IMPORTANT: The STS remembers the password for a site based on the site ID. However, if you specify Local in the connection bar, or use a site ID which is not part of the project, the STS has no record of its password. Therefore, this communication will fail if the site uses a different password than the STS. If an RTU fails to communicate after MDLC password change, there may be a localized problem, which caused the RTU rolled back to the previous configuration and password. In this situation, the configuration can be downloaded locally, or the user can try to communicate with the RTU by overriding the password with the previous password. For details, see the Overriding the MDLC Password in the ACE3600 STS User Guide. The user can choose to leave MDLC password update mode before all sites are updated (e.g. if a site was updated locally due to communication problems.) In this case, the STS restarts the MDLC driver with the new password and all old passwords which were saved are erased permanently. For additional information on MLDC passwords in secured systems, see the ACE3600 Advanced System Security manual.

154

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. 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 can be configured to save some information from the system memory before the reset, in order to help pinpoint the failure (Reduced functionality.) This information may contain descriptive messages, register values, decoded function callback traces of the failure from the system memory, the task that caused the failure, etc. To save the information, the RTU freezes all tasks for a short period of time, several milliseconds, before it resets the RTU. After the restart, the unit becomes active again. This information is logged to the Error Logger. The Core Dump feature is configured in the ACE3600 STS site configuration using the SMA Online advanced parameter in the Core Dump category. Reduced functionality is the default setting. See Appendix A: Site Configuration Parameters in the ACE3600 STS User Guide. IMPORTANT: It is not recommended to set SMA Online to Disable.

155

MDLC Encryption The MDLC Encryption add-on feature enables encrypted 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 RTUs with firmware version
156

Protocol Analyzer The Protocol Analyzer is a diagnostic tool which enables the user to monitor and analyze MDLC communication over various channels in two different ways: • By means of an additional RTU defined as an adaptor that collects data for the Protocol Analyzer. This adaptor monitors one port and transfers the received data through a second port to the Protocol Analyzer program. • By monitoring the communication between two RTUs through RS-link, between a computer and RTU through a computer Port, or between an RTU and an external modem. This way of monitoring requires two 8 pin-to-25 pin female adaptors and two serial ports on the STS computer. a) Monitoring a Radio Link The additional RTU should include a CPU module, radio and power supply. Using the STS site configuration program, configure a CPU Port (e.g. port SI1) as RS232, Async, Protocol Analyzer Port. The CPU receives through a radio port all the frames (without address checking) transmitted in the radio link, and transfers them through the Protocol Analyzer port to the STS computer for evaluating, storing and displaying. The radio port (e.g. PI2) should be defined according to the type of radio being used. A third port (port SI2) can be defined as Computer Port to enable reconfiguration of the CPU (back to normal mode of operation). After configuring the CPU as a Protocol Analyzer, the following connections should be performed as depicted below:

157

Protocol Analyzer

RTU

FIU FIU CENTRAL

RTU

PROTOCOL ANALYZER

PORT

PI1

PORT

SI1

PORT

SI2

RADIO

PORT

PI2

STS

CPU MODULE

b) Monitoring a Multi-Drop Link 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

STS

PI2

2-WIRE MULTI-DROP ADAPTER

CPU MODULE

158

Protocol Analyzer

c) Monitoring an RS-232 Link The communication on an RS-232 link (such as RS-link or Computer Port) is full-duplex. Usually, there is no need to monitor this type of communication. Nevertheless, if you have to monitor this type of communication, perform the following connections – see the following figure: STANDARD MOSCAD ADAPTER (MALE or FEMALE) FULL-DUPLEX MDLC PROTOCOL

ACE3600 RTU

TO COMPUTER OR ACE3600 SITE

MONITORED RS-232 8-pin T-connector

TO PORT SI1

TO PORT SI2

25-PIN FEMALE ADAPTER

STS PROTOCOL ANALYZER

Since the communication is full-duplex, two ports of the STS are used. You should use two standard 8-pin T-connectors and two 25-pin female adaptors: one monitors the Tx Data and the second the Rx Data of the communication – refer to the following table. Adaptor for RTU Tx Monitoring

Adaptor for RTU Rx Monitoring

8-pin

25-pin female

Function

8-pin

25-pin female

Function

1

3

STS Rx Data

2

3

STS Rx Data

4

7

GND

4

7

GND

7 (+12V)

6

DSR

7 (+12V)

6

DSR

Protocol Analyzer Program The Protocol Analyzer program monitors the data transmitted in the communication channels and displays the analyzed data. The Protocol Analyzer may analyze any link in the system. The Protocol Analyzer is run from the Windows Start->Programs->STS>Protocol Analyzer command. When you start up the Protocol Analyzer utility, the following screen is displayed:

159

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.

Setting Communication Monitoring Parameters 1. To specify the parameters for monitoring communication on a local link, select the Local Communication command from the Monitor menu. Result: The Set Local Communication Parameters dialog box is opened, as shown below.

160

Protocol Analyzer

To specify the parameters for monitoring communication on a remote link, select the Remote Communication command from the Monitor menu. Result: The Set Remote Communication Parameters dialog box is opened, as shown below.

161

Protocol Analyzer

2. Enter the names (e.g. COM1) of the ports of the RTU to which the protocol analyzer is connected. The order is irrelevant. For a remote link, only one port is defined. 3. Enter the data speed of the link being monitored. 4. Enter the system address of the link being monitored. 5. Enter the name of the log file in which the monitored data should be collected (the default is monc.dat.) You can click on the browse icon to select the name of the desired .dat file. The Open dialog box defaults to the log sub-directory of the STS directory where STS stores log files by default. The raw log file include the source site, the number of bytes that were collected (size of the frame) and the frame contents. 6. As of STS V16.00, you can define the file interval (in minutes) at which log files should be created. -If the file interval is 0, all monitored data is collected in one log file. Because this file may include many days worth of data, it could be very large. Analyzing the data and pinpointing specific events could be very time consuming. -If files are created at intervals (minimum is 1 minute; maximum interval is 1440 minutes or one day), the log files are smaller. Therefore, analyzing the data and pinpointing specific events is easier. After the interval, the MDLC Protocol Analyzer will wait for the next communication before creating the next log file. 7. Click on the desired format to be used (MDLC frames or Free Format). 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.

8.

Once the parameters are set, you are ready to start monitoring.

Monitoring the Communication on a Link 1. Once the parameters are set, click the Start button to start monitoring. Result: The screen will clear, the new log file name will appear at the top of the window and data sent over the link will begin to appear in the window.

162

Protocol Analyzer

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. 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).

Opening an Analyzed File 1. To open and view an existing file of analyzed information, select the Open Analyzed File command from the File menu. Result: A dialog box is opened from which the user can select the desired .mon 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. 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).

163

Protocol Analyzer

Analyzing a Log File 1. To perform analysis on the current log file of raw data from the communication link, select the Analyze Log File command from the File menu. Note: If the Protocol Analyzer was configured to create files at intervals, and you stop monitoring and click on the Analyze Log File (pencil) icon, the file to be analyzed is the current file displayed, i.e. the most recent one that was created. Result: The Set MDLC Layers to Analyze dialog box opens, as shown below.

164

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 secured systems which use the AES algorithm, check the MDLC Encryption details field. In the Key field, paste the Key Value of the key that was active when the data in the log file to be analyzed. In the IV field, paste the IV of the key that was active when the data in the log file to be analyzed. (These may be copied from the Security->Keys window.) IMPORTANT: If the proper key and IV are not provided, the log file cannot be decrypted and analyzed. In nonsecured systems or systems which use the TEA algorithm, the MDLC Encryption details field should be unchecked. 5. Once the preferences have been defined, click OK to begin the data analysis. 165

Protocol Analyzer

Previewing a File before Printing To see how the current file will look when printed, select the Print Preview command from the File menu. This command functions like the standard Windows Print Preview command.

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.

Exiting the Protocol Analyzer tool To exit the Protocol Analyzer tool, select the Exit command from the File menu.

166

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:

OUT (t ) = I 0 + KKi ∫0 E (t )dt + KE (t ) + KKd t

where:

167

dE ( t ) dt


IN(t) the PID input that represents the measured process value in "Input Engineering Units" [IEU]. SP(t) -

the setpoint value in [IEU].

E(t) -

the error signal.

OUT(t) - the output of the PID loop in "Output Engineering Units" [OEU]. K-

the gain of the loop in [OEU/IEU].

Ki -

integration factor in "repetitions per second" [l/sec].

Kd -

derivative factor in seconds.

I0 the initial value of the integral (when t=0) in [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 proportional calculation, whose contribution to the output signal is directly proportional to the error signal. • The integration, whose contribution to the output signal is proportional to the integral of the error between 0 to t plus I0, which serves as the initial value of the integral (for t=0). The integral drives the process of the setpoint value with a zero position error. • The derivation, whose contribution to the output signal is proportional to the rate of change of the error signal.

PID Table To access the PID table, open an application using the Application Manager in the STS, the Application Manager command in the STS GUI or the Application Programmer utility in STS Start Menu program list. In the Database tab, click on User Tables to open the list of database user tables, as shown below.

168


• If no PID Table appears in the list of user table names, it must be created. Right-click on the User Tables and select Append Table -> PID Table from the context menu. • If PID Table appears in the list of user table names, double-click its name in the table name list. The following is displayed:

The PID table includes the following parameters. For more details on each parameter, see the example project: •

pidIN - the scaled analog input (32-bit floating point value) that represents the controlled process. The value in this column is updated when the SCAN function using this column name is called.

169


•

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

•

pidInt - this is the integral section in the equation above, i.e. 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

The value of this variable may be modified in the rungs. •

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.

How to Use the PID In order to use the PID, the PID table and other User database tables are built in the Application Programmer, with variables corresponding to physical elements. Process rungs are programmed in the Ladder Diagram language which define the behavior of outputs as a function of the states and their inputs and time. An analog input is scanned, the PID function is called to perform the PID loop and then the analog output of the PID loop is scanned. 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.

170


PID Application Example 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

PID control function A PID control function is used to set an analog output as a function of a process setpoint and a feedback analog signal of the controlled value. The function include three adjustments, each of which is represented in the PID table by a variable: •

Proportional (pidK variable)

•

Integral (pidKi variable)

•

Derivative (pidKd variable)

The application includes additional features, such as: •

Operation Mode – Manual (set by operator) or Automatic (PID) mode.

•

Validity Check - The process variables are to be within a predefined valid range.

•

Cycle time - Time interval between consecutive calculations of PID function

The impact of the three adjustments of the PID is as follows: 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. 171


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).

172


Database Tables The database tables are shown below. Each variable used in the tables is described.

Operator Interface Table This table contains the variables that can be set by the operator who controls the process via an HMI station: Table name: Operator Interface Table symbol: Ind

CV_Set (int)

AO_Set (int)

0

COS name: Last index (Ind): 0 Last index name: LstPid ModSet (iprm) 0

CV_Set - Controlled Value setting for PID loop in Auto mode AO_Set - Analog Output setting for PID loop in Manual mode ModSet - Setting of PID loop Operation mode (1 = Auto, 0 = Manual)

PID Table Table name: PID Table Table symbol:

Ind

pidIN (sAI)

0

Ind

pidIN

0

Ind 0

PidOUT

COS name: Last index (Ind): 0 Last index name: I_PID

pidSP (rprm)

pidK (rprm)

pidKd (rprm)

pidKi (rprm)

pidInt (rprm)

PidDb (rprm)

0.0

3.0-4

0.0

10.0

0.0

0.0

EGU Zero (%)

EGU Zero

EGU High 100%=Full Scale

0%

0.0

1.0

EGU Zero (%) EGU Zero


0%

1.0

0.0

The PID function runs according to the following variables: 173

PidOUT (sAO)


pidIN - PID controlled value input. - Represents the controlled value (CV). This value is not linked directly to the analog input and is updated by application. The scaling of the input can be defined in this column, by setting the EGU Zero and EGU High accordingly. pidSP - Represents the process setpoint (SP) 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.

PID I/O Table This table is used to link the process CV analog input and AO analog output. The values are scaled to 0 - 100 percent. Table name: PID I/O Table symbol:

Ind

COS name: Last index (Ind): 0 Last index name:

Pid_AI (sAI)

Pid_AO (sAO)

Pid_AI

EGU Zero (%)

EGU Zero


20%=Live Zero

0.0

100.0

EGU Zero (%)

EGU Zero


0

Ind 0

Ind

Pid_AO

174


0

20%=Live Zero

0.0

100.0

Pid_AI - PID loop controlled value analog input (linked to an AI module) Pid_AO - PID loop analog output (linked to an AO module) EGU Zero–used to define the scaling of the PID controlled value input pidIN EGU High –used to define the scaling of the PID controlled value input pidIN

PID P & I Parameters Table These parameters are used to define the basic proportional and integral factors. Table name: PID P & I Parameters Table symbol:

Ind

PID_P (rprm)

PID_I (rprm)

0

3.0-4

10.0


PID_P - Proportional factor (also multiplies the Integral part) PID_I - Integration factor

PID Parameters Table This table includes user definable parameters that are used to check validity of input (CV) or output (AO) of the PID function. Table name: PID Parameters Table symbol:


Ind

AlrDB (rprm)

AlrTim Mn:Sc

CV_Min (rprm)

CV_Max (rprm)

AO_Min (rprm)

AO_Max (rprm)

0

5.0

05:00

0.0

15000.0

0.0

100.0

AlrDB - PID alarm dead band (percent of full scale) AlrTim - Time delay to set the PID alarm flag. This alarm indicates that the PID process value did not reach the setpoint within the AlrDB range within this time delay. CV_Min - Minimum value of CV (controlled value) CV_Max - Maximum value of CV (controlled value) AO_Min - Minimum value of AO (analog output) AO_Max - Maximum value of AO (analog output) 175


PID Flags Table The variables of this table are used for checking the existing error (SP-CV) of the PID loop. Table name: PID Flags Table symbol:

Ind

PidDif (real)

DifTmp (real)

COS name: Last index (Ind): 0 Last index name: RTemp (real)

O_Max (bit)

O_Min (bit)

PidAlr (bit)

0

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)

Second Timers Table Table name: Second Timers Table symbol: Data type: Timers Second Ind

Name

Value

0

TPID

01:00

COS name: Last index (Ind): 0 (Sc:Ms)

TPID - PID calculation time interval (multiplied by 10 ms). The timer preset value is set by PtPID.

User Flags Table Table name: User Flags Table symbol: Data type: Discrete (bit) Ind

Name

0

BTemp

COS name: Last index (Ind): 0

Value

176


Btemp - Temporary flag

User Parameters Table Table name: User Parameters Table symbol: Data type: Integer Parameter (iprm) Ind

Name

Value

0

PtPID

100

COS name: Last index (Ind): 0

PtPID - A parameter to set PID calculation time interval (10msec resolution). The minimum setting for running 8 PID loops is 100 (1 second).

Constants The application uses the following constants: Integer Constants - Manual = 0, Auto = 1 Real Constants - R0 = 0.0, R100 = 100,0

Programming Process Rungs The chart below lists the rungs which have been programmed for application. Rung P05 P10 PL10 PL12 P18 P20 P21 P25 P30 P50 P60 P90 M91

Description Scan PID AI Reset Index p Local Setpoints Local Setpoints Manual mode limits Manual Mode Jmp P50 if no TPID Auto Mode Check Input range Increment Index p Check Index p Run PID Calc Jmp P200 if no TPID 177


P100 P110 P112 P113 P114 P115 P130 P140 P200 P210

Reset Index p Check Output range Calc PID loop error Set PI factors Set O_Max flag Set O_Min flag Increment Index p Check Index p Scan analog output Run PID Timer

The following are the actual rungs of the application. Rung P05: Scan the analog input (CV) of the PID loop. Pid_AI (SCAN)

P05

Rung P10: The number of PID loops which are controlled by the application is set by the number of rows in the PID Table. The same application with an index 'p' handles all loops. This rung resets 'p' index to run the first PID loop. p ( RST )

P10

Rung PL12: In Auto mode, the Pid_AO is always copied to AO_Set. This enables smooth transition to Manual mode without a step change in the loop SP. PL12

AO_Set,p (MOVE) Pid_AO,p

ModSet,p = Auto

Rung P18: In Manual mode, the AO_Set value is checked to be within a predefined range (AO_Min and AO_Max). If it exceeds these limits, the output is set to the relevant limit. P18

ModSet,p AO_Set,p > = AO_Max Manual

Pid_AO,p (MOVE) AO_Max,p

AO_Set,p < AO_Min

Pid_AO,p (MOVE) AO_Min,p

178


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. In addition, the AO_Set value is checked to be within a predefined range (AO_Min and AO_Max) and is copied to Pid_AO, and PidInt. Updating the latter variable is also important to keep the AO in the last position when loop mode is changed to Auto, while there is no change in the setpoint. P20

ModSet,p Pid_AI,p > = Manual CV_Min,p

Pid_AI,p > CV_Max,p

Pid_AI,p = CV_Min,p

Pid_AI,p = CV_Max,p

AO_Set,p AO_Set,p > < AO_Min AO_Max AO_Set,p AO_Set,p = = AO_Min AO_Max

pidSP,p (MOVE) Pid_AI,p

CV_Set,p (MOVE) pidSP,p Pid_AO,p (MOVE) AO_Set,p

pidInt,p (MOVE) Pid_AO,p

Rung P21: Skips the next two rungs when PID loop is not calculated.

P21

TPID /

P50 ( JMP )

Rung P25: In Auto mode, the CV_Set (set by the operator) is checked to be within a predefined range (CV_Min and CV_Max) and copied to PidSp. In addition the AO_Set value is updated by the Pid_AO. P25

ModSet,p CV_Set,p > = Auto CV_Min,p

CV_Set,p < CV_Max,p

CV_Set,p = CV_Min,p

CV_Set,p = CV_Max,p

179

pidSP,p (MOVE) CV_Set,p

AO_Set,p (MOVE) Pid_AO,p


Rung P30: In Auto mode, the Pid_AI is checked to be within a predefined range (CV_Min and CV_Max) and copied to PidIn accordingly. P30

ModSet,p Pid_AI,p > = Auto CV_Min,p

Pid_AI,p < CV_Max,p

Pid_AI,p = CV_Min,p

Pid_AI,p = CV_Max,p

pidIN,p (MOVE) Pid_AI,p

Pid_AI,p > CV_Max,p

pidIN,p (MOVE) CV_Max,p

Pid_AI,p < CV_Min,p

pidIN,p (MOVE) CV_Min,p

Rung P50: Counts up (increments) the index counter (to execute the next loop). p ( CTU )

P50

Rung P60: Checks the index counter. p < I_PID

P60

PL10 (JMP)

p = I_PID

Rung P90: Runs the PID calculation on all loops every TPID interval. TPID

P.I.D. ( CALL )

P90

Rung M91: Skips the next rungs, which check the PID function results, if PID function was not performed.

M91

TPID /

P200 ( JMP )

180


Rung P100: Resets a new index. p ( RST )

P100

Rung P110: Checks the PidOut (PID function output) to be within a predefined range (AO_Min and AO_Max), and copies it to Pid_AO accordingly. P110

ModSet,p pidOUT,p < = AO_Min,p Auto

Pid_AO,p (MOVE) AO_Min,p

pidOUT,p > AO_Max,p

Pid_AO,p (MOVE) AO_Max,p

pidOUT,p pidOUT,p > < AO_Min,p AO_Max,p

Pid_AO,p (MOVE) pidOUT,p

pidOUT,p pidOUT,p = = AO_Min,p AO_Max,p

Rung P112: PID loop performance is checked. If the output fails to be within a predefined range (PidSp +/- AlrDB) for longer than AlrTim, an alarm flag (PidAlr) is set. P112

PidDif,p - pidSP,p Pid_AI,p

ModSet,p = Auto

DifTmp,p (MOVE) PidDif,p DifTmp,p < R0

DifTmp,p - R0 DifTmp,p RTemp,p (CALC)

RTemp,p > AlrDB,p AlrTim,p

AlrTim,p (DON) PidAlr,p ( )

RTemp,p = DifTmp,p/(CV_Max,p - CV_Min,p) * (R100)

181


Rung P113: In order to prevent large fluctuations in output when Rtemp (process error in percents) is greater than AlrDb (user defined parameter), the application divides the PidK by a constant 100. In order to keep the integral factor unchanged, it is multiplied by the same constant. Thus, the Integral action is dominant when process error is large, and the Proportional action is more dominant when process error is small. P113

ModSet,p RTemp,p > = AlrDB,p Auto

pidK,p / PID_P,p R100

RTemp,p = AlrDB,p

pidKi,p x PID_I,p R100 pidK,p (MOVE) PID_P,p

RTemp,p < AlrDB,p

pidKi,p (MOVE) PID_I,p

Note: The constant is used for the example only. For a practical PID loop, the proper constant (or other type of handling these factors) must be implemented.

Rung P114: In Auto mode, when PidOut exceeds AO_Max, it is kept at that level. The first time the process error becomes negative, the AO_Max is copied to PidInt. This operation eliminates the effect of positive accumulated value of the Integral portion when AO is in its maximum position. P114

O_Max,p ( L )

ModSet,p pidOUT,p > = Auto AO_Max,p O_Max,p

PidDif,p < R0

pidInt,p (MOVE) AO_Max,p O_Max,p (U )

182


Rung P115: In Auto mode, when PidOut exceeds AO_Min, it is kept at that level. The first time the process error becomes positive, the AO_Min is copied to PidInt. This operation eliminates the effect of negative accumulated value of Integral portion when AO is in its minimum position. P115

ModSet,p pidOUT,p < = Auto AO_Min,p O_Min,p

O_Min,p ( L ) PidDif,p > R0

pidInt,p (MOVE) AO_Min,p O_Min,p (U )

Rung P130: Counts up (increments) the index counter (to execute the next loop). p ( CTU )

P130

Rung P140: Checks the index counter. P140

P110 ( JUMP )

p < I_PID p = I_PID

Rung P200: Writes the resulting analog output to Pid_AO by Scan operation. Pid_AO ( SCAN )

P200

Rung P210: Sets and runs the TPID timer. TPID (MOVE) PtPID

TPID P210 TPID /

TPID (DON)

183

Enhanced PID The ACE3600 Enhanced PID Application enables the ACE3600 to control up to 32 independent PID loops (independent processes), each with five PID modes: one manual and four types of auto modes. The PID calculation algorithm depends on the chosen mode. The ACE3600 Enhanced PID Application includes a powerful tool for graphically monitoring the control process, which also enables interactive PID coefficient tuning. If a legacy PID loop application exists in the RTU, an Enhanced PID application can also be defined for the RTU. The Enhanced PID Application is installed as a separate add-on option (FVN5680A) to the STS. For more information, see the ACE3600 Enhanced PID Application User Guide, provided with the STS installation in [C]:\STS\STSManuals when the add-on is installed.

184

Irrigation The ACE3600 STS can be used to build, configure and maintain sophisticated distributed SCADA-based (Supervisory Control and Data Acquisition) irrigation systems. The elements and handling of irrigation systems differ slightly from other SCADA systems. An irrigation system consists of an IRRInet Control Center (ICC), field units (RTUs) and portable device for on-site programming of field units. For detailed information on planning and setting up an irrigation system, see the IRRInetM System Planner.

Irrigation Unit Types The STS supports the following irrigation system three field unit types: IRRInet-ACE, IRRInet-M (as Master) and IRRInet-M (as Slave). For detailed information on the field units and irrigation functions, see the IRRInet-M System Planner. For detailed information on using the STS to configure and deploy units, see the ACE3600 STS User Guide. References to ACE3600 in the ACE3600 STS User Guide apply to IRRInet-ACE RTUs as well, except where noted otherwise. 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. The IRRInet-ACE supports two modes of operations: •

RTU – Performing all irrigation functions, reporting to the IRRInet Control Center (ICC).

•

Stand Alone – Performing all irrigation functions as a stand-alone unit when the system is installed without an ICC.

With DIOS (Distributed I/O System) connectivity, the IRRInet-ACE can activate PiccoloXR units with its PIU (Piccolo Interface Unit) functionality. The IRRInet-ACE RTU can be programmed on site, using an IRRinet Terminal for Pocket PC. The IRRInet-ACE may be installed in a totally new irrigation system, or in a legacy system in addition to/instead of a legacy IRRInet-XL or IRRInet-XM unit.

185

Irrigation

IRRInet-M Master/Slave There are two types of IRRInet-M: •

IRRInet-M AC (for AC solenoids)

•

IRRInet-M DC (for DC solenoids)

The IRRInet-M RTU supports three modes of operations: •

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.

STS Functions for Irrigation Units The ACE3600 STS can be used to perform the following functions on IRRInet-M units, either via local connection or via the communication network. •

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.

186

Irrigation

Tips on Using the STS for Irrigation Toolbox for Irrigation For legacy irrigation systems, MOSCAD Programming ToolBox 9.54 should be installed on the PC along with the ACE3600 STS software.

Defining and Configuring an IRRInet-M RTU When defining an IRRInet-M unit, follow the instructions in the Operation chapter of the ACE3600 STS User Guide. Differences between handling an IRRInet-M unit and an ACE3600/IRRInet-ACE unit are specified in the individual procedures. 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.

Network Configuration in Irrigation Systems The figure below illustrates an irrigation system, with an RTU (FIU) connected to the STS PC via RSlink19 and a set of RTUs (IRRInet-ACE or IRRInet-M) which communicate with the FIU via radio link, and with PIU/Scorpio units via RSlink1 or RSlink2. IRRInet-ACE/ IRRInet-M Masters Radio1

IRRInet-M Slaves/Routers

PIU

RSlink1 RTU 1 RSlink2

STS PC

RTU 101

Radio (Intrac)

Radio1 RTU 2 RSlink2

Scorpio

PIU

RSlink1

RSlink19 RTU 100

Legacy Units

RTU 102

Radio (Intrac)

Scorpio

Radio1 PIU

RSlink1

FIU RTU 3 Radio1

RSlink2

. .

RTU 103

Radio (Intrac)

PIU

RSlink1

RTU 99 RSlink2

Scorpio

RTU 199

Radio (Intrac)

Scorpio

Irrigation systems such as the one depicted above should not use the generic network configuration table produced automatically by the STS. Instead, a customized network table should be created and maintained, as follows: 1. After defining two connected sites (RTU 100 and RTU 1) with their links (RSlink19 and Radio1 for RTU 100, and Radio1, RSlink1, RSlink2 for RTU 1), save the generic network configuration table produced by the STS as a private network table. (See the Managing the Network and Editing a Network Table sections in the Operation chapter 187

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.

Legacy Irrigation RTUs The STS does not support legacy irrigation units. However, the STS can be used with IRRInet-XM and IRRInet-XL legacy units, as follows: To define an IRRInet-XM module, drag the Legacy->MOSCAD entry in the inventory. To define an IRRInet-XL module, use the Legacy->MOSCAD-L entry in the inventory. Although the RTUs that are created will be marked as MOSCAD/MOSCAD-L in the STS GUI, you can download relevant Irrigation files to the RTUs and retrieve errors and diagnostics from them. 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. File Type

File Extension

Ladder Application

.b, .s

PLC 1, 2, 3

.fls

PLC to Master 1, 2, 3

.fls

‘C’ Application

.fls

IP Configuration

.ipp

188

Irrigation

File Type

File Extension

‘C’ Application Parameters

*.*

IP Conversion Table

.ipc

IMPORTANT: Because the irrigation system works with ICC V14, all legacy irrigation RTUs must be upgraded to V570 of the project files.

189

Project Synchronizer The ACE3600 STS Project Synchronizer enables the system administrator to compare two projects and import changes from one project into the other. The ACE3600 STS Project Synchronizer is installed as a separate add-on option to the STS, from the STS CD. For more information, see the ACE3600 STS Project Synchronizer manual, provided with the STS installation in [C]:\STS\STSManuals when the add-on is installed.

190

Appendix A: Accessories, Adaptors, and Cables Note: On all of the Motorola RJ45 connector heads (except for Ethernet cables), the numbering of the pins is different than the standard, as shown in the figure below. Pin 1-8 are left to right rather than right to left, as shown below. Therefore, only original Motorola cables should be used.

This appendix provides the information required for connecting an RTU RS232 port to various units, as detailed below: •

Connection to a Computer or Terminal (MDLC protocol or User port, USB Device port)

•

Connection to a Modem (MDLC protocol or User port)

•

Connection to GPS Receiver (Motorola Binary protocol)

•

Connecting a User Port to a Printer

•

Connecting a User Port to an External Unit

•

Connection to a Radio (MDLC and PPP protocols)

•

RTU-to-RTU Connection Using MDLC Protocol through RS232 Ports (RS-Link)

•

ACE3600 RTU-to-ACE3600 RTU Connection Using MDLC Protocol through RS485 Ports (RS-Link)

•

ACE3600 RTU-to-MOSCAD RTU Connection Using MDLC Protocol through RS485 Ports (RS-Link)

•

ACE3600 RTU-to-PC Ethernet Port Direct Connection without Hub

•

ACE3600 RTU Main CPU to Expansion Module Direct Connection (for systems with I/O expansion only)

•

ACE3600 RTU Main CPU to Expansion Module Connection via LAN Switch - CPU to expansion LAN switch connection or connection of the first LAN switch to the second, if such exists (for systems with I/O expansion only)

•

ACE3600 RTU Main CPU to Expansion Module Connection via LAN Switch - LAN switch to expansion module connection (for systems with I/O expansion only)

Connection to a Computer or Terminal To connect one of the RTU RS232 ports to a computer/terminal, use the FLN6457B adaptor, which ends with the female 25-pin or 9-pin, D-type connector. The port may be defined either as a MDLC protocol port or as a User port. A-1

Appendix A: Accessories, Adaptors and Cables

The signals that appear on the female 25-pin or 9-pin D-type connector are according to the RS232 standard – see the following table. In this case, the RTU serves as DCE (Data Communication Equipment). RS232 Function

8-pin Connector (on RTU)

25-pin Female

9-pin Female

Direction

TX-DATA

2←

2

3

from DTE

RX-DATA

1→

3

2

to DTE

RTS

5←

4

7

from DTE

CTS

8→

5

8

to DTE

DSR

7→

6

6

to DTE

GND

4

7

5

-

DTR

3←

20

4

from DTE

DCD (Rec line)

6→

8

1

to DTE

To extend the cable, you may use any extension cable with male and female D-type connectors (connected pin-to-pin, not crossed). Note: When a User port is defined as Computer/Terminal with DTR support: 1) The RTU will not transmit unless it receives DTR=ON from the computer/terminal. 2) The RTU will not receive unless it receives RTS=ON from the computer/terminal.

To connect the RTU USB device port (DU1) to a computer, use a standard USB 2.0 A to B device cable. Connect the USB 2.0 standard A (male) USB plug on the PC/host side and the USB 2.0 standard B (male) plug on the RTU side. All standard cable restrictions (e.g. maximum length of 5 meters) apply.

To connect the RTU to a PC via the Ethernet port, see ACE3600 RTU-to-PC Ethernet Port Direct Connection without Hub.

Connection to a Modem To connect one of the RTU RS232 ports to an RS232 modem, use one of the adaptors provided in kit FLN6458B (option V213AE): •

9-pin adaptor for Async (#0189968V32)

•

RS232-E adaptor (#0189968V33) as in Connection to IDEN Radio below.

•

RS232-E+ adaptor (#0189968V34) as in Connection to TETRA Radio below. A-2


The asynchronous adaptor (#0189968V32) ends with the male 9-pin D-type connector. The port may be defined either as a MDLC protocol port or as a User port. The signals that appear on the male 9-pin D-type (or 25-pin) connector are according to the RS232 standard – see the following table. In this case, the RTU serves as DTE (Data Terminal Equipment). RS232 Function

8-pin Connector

25-pin Male

9-pin Male

Direction

(on RTU)

TX-DATA

1→

2

3

from RTU

RX-DATA

2←

3

2

to RTU

RTS

6→

4

7

from RTU

CTS

3←

5

8

to RTU

GND

4

7

5

-

DTR

8→

20

4

from RTU

DCD (Rec line)

5←

8

1

to RTU

To extend the cable, you may use any extension cable with male and female D-type connectors (connected pin-to-pin, not crossed). Before transmitting, the RTU sends RTS=ON to the modem, and waits for CTS=ON from the modem as a condition for transmitting. The RTU will receive data from the modem only when DCD=ON. When using a modem in auto-answer mode (connected to a Computer port) for remote service, the RTU does not support RTS/CTS protocol since the port is designated to operate with a local computer as well as with a modem. For modems which support RS232-E, use either the RS232-E adaptor (#0189968V33) as in Connection to IDEN Radio below, or the RS232-E+ adaptor (#0189968V34), as in Connection to TETRA Radio below.

Connection to GPS Receiver When an off-the-shelf GPS timing receiver is purchased (e.g. Synergy SynPaQ/E PPS Sensor with M12+, Garmin NMEA 2000), the data and power cable for that receiver should be purchased as well. Connect the data wire of the cable to the CPU port using the ACE3600 asynchronous RS232E adaptor cable. The port should be defined as a GPS receiver port (RS232, Async). Connect the power wire of the cable to a cable with the following connectors: RTU side: The connector should fit the auxiliary power connector on the ACE3600 power supply module. A-3


GPS Receiver side: The connector should fit the power connector on the GPS receiver cable. When connecting a Garmin GPS with RJ45 connector to the ACE3600 RTU, use an Async RS232-E adaptor and a custom RJ45-to-D9 female adaptor. The connection chain is: Garmin GPS RJ45 -> customer RJ45 to D9 female -> Async RS232E adaptor -> ACE3600 GPS port. To make the RJ45-to-D9 female adaptor, refer to the following table. RTU RS232 Function

Adaptor D9 Female (connects to the RS232-E adaptor)

Adaptor’s RJ45 pin# (connects to GPS RJ45)

TX (from RTU)

3

4 (Din)

RX (to RTU)

2

5 (Dout)

CTS (to RTU)

8

-

GND

5

2,3 (GND, remote ON)

CD (to RTU)

1

6 (PPS)

DTR (from RTU)

7

-

-

1 (PWR)

PS

PS GND

PS PWR

Connecting a User Port to a Printer To connect one of the RTU RS232 ports defined as a User port to a printer, you may use one of the two cables described in the previous paragraphs. Since the connection to the printer is not defined by the RS232 standard, every printer manufacturer has defined the connectors for his own convenience. Therefore, select the adaptor according to the functions of the various pins. If the FLN6458B adaptor (with the male 9-pin D-type connector) is used, refer to the following table. RS232 Function

9-pin Male

Used as

Direction

TX-DATA

3

Serial Data

to Printer

CTS

8

Printer Ready

from Printer

GND

5

GND

-

If the FLN6457B adaptor (with the female 9-pin, D-type connector) is used, refer to the following table.

A-4


RS232 Function

9-pin Female

Used as

Direction

RX-DATA

2

Printer Rx-Data

to Printer

DTR

4

Printer Ready

from Printer

GND

5

GND

-

Connecting a User Port to an External Unit To connect one of the RTU RS232 ports defined as a User port to an external unit (which supports RS232), you may use one of the two adaptors (FLN6457B or FLN6458B) according to the port definition in the site configuration. If the FLN6457B adaptor is used, refer to the pin assignment given in Connection to a Computer or Terminal in this chapter. If the FLN6458B adaptor is used, refer to the pin assignment given in Connection to a Modem in this chapter.

Connection to a Radio For detailed instructions on connecting a radio to the ACE3600 RTU, see the Radio Types and Installation Kits chapter in the ACE3600 RTU Owner’s Manual.

Connection to IDEN Radio To connect the RTU (via onboard serial or plug-in port) to an IDEN radio, use an adaptor which ends with the male 9-pin, D-type connector. The port should be defined as RS232, Async, PPP, iDEN, MDLC over IP. RS232 Function


9-pin Male

Direction

TX-DATA

1→

3

from RTU

RX-DATA

2←

2

to RTU

CTS

3←

8

to RTU

GND

4

5

-

CD (Rec line)

5←

1

to RTU

RTS

6→

Not used

7→

4

from RTU

8→

7

from RTU

DTR

A-5


Connection to TETRA Radio To connect the RTU (via onboard serial or plug-in port) to a TETRA radio, use an RS232-E+ type adaptor which ends with the male 9-pin, D-type connector. The port should be defined as RS232, Async, PPP, Tetra, MDLC over IP. RS232 Function


9-pin Male

Direction

TX-DATA

1→

3

from RTU

RX-DATA

2←

2

to RTU

CTS

3←

8

to RTU

GND

4

5

-

CD (Rec line)

5←

1

to RTU

RTS

6→

4

from RTU

7

Not used

8→

7

DTR

from RTU

Connection to MotoTrbo Radio To connect the RTU (via Host USB port) to a MotoTrbo radio, use the FKN8644A cable. The port should be defined as USB Host, Async, Remote NDIS Host, MotoTrbo. Function

USB Type A (on RTU)

26-pin Female (on Radio)

Direction

+5 VDC/ VBUS+

1→

3

from RTU

Data -

2↔

2

to/from RTU

Data +

3↔

1

to/from RTU

GND

4

4

-

25

from radio power cable

Ignition

RTU-to-RTU Connection Using MDLC Protocol through RS232 To establish a link between two RTUs using MDLC protocol, the ports of both RTUs should be defined as RS232 RTU-to-RTU (RS-Link). The ports of the two RTUs should be connected by the FLN6457B and FLN6458B adaptors, when the adaptors are connected.

A-6


!

IMPORTANT Do not connect between RTUs without the adaptor cables. A direct connection will cause a short circuit between the pins that have the same function.

RTU-to-RTU Synchronous Communication Using Plug-in Port The pin assignment of the cable to be used for RTU-to-RTU synchronous communication (using a plug-in port) is given below. RS232 Function

8-pin Connector (on sending RTU)

8-pin Connector (on receiving RTU)

Direction

TX-DATA

1→

2←

from RTU

RX-DATA

2←

1→

to RTU

CTS

3 + 6 →∗

5←

from RTU

Signal GND

4

4

-

CD (Rec line)

5←

3 + 6 →∗

to RTU

RTS

6 + 3→∗

5←

from RTU

TX_CLK

7→

8←

from RTU

RX_CLK

8←

7→

to RTU

*Pins 3 and 6 are shorted.

ACE3600 RTU-to-ACE3600 RTU Connection Using MDLC Protocol through RS485 To establish a link between more than two ACE3600 RTUs using MDLC protocol, the ports of all RTUs should be defined as RS485 RTU multidrop. The ports of the RTUs should be connected using the RS485 connection box V186AD (FLN3641A). Cable FKN8427A should be connected between ACE3600 RS485 port and one of the seven inlets of the connection box. RS485 Function

8-pin Connector * (on ACE3600)

B (RX/TX-)

1

A (RX/TX+)

8

* Note: All seven connectors are shorted.

A-7


ACE3600 RTU-to-MOSCAD RTU Connection Using MDLC Protocol through RS485 To establish a link between an ACE3600 unit and a MOSCAD RTU using MDLC protocol, the ports of both RTUs should be defined as RS485 RTU multidrop. The ports of the two RTUs should be connected using the FKN8527A cable.

!

IMPORTANT Do not connect between RTUs without the adaptor cables. A direct connection will cause a short circuit between the pins that have the same function.

RS485 Function

8-pin Connector (on ACE3600)

4-pin Connector (on MOSCAD)

B (RX/TX-)

1

2

A (RX/TX+)

8

3

ACE3600 RTU-to-PC Ethernet Port Direct Connection without Hub Note: The RJ45 connector head for this connection is standard. The numbering of the pins is according to the standard, as shown in the figure below. Pin 1-8 are right to left, as shown below. Therefore, any standard Ethernet crossover cable may be used.

To establish a link between an ACE3600 unit and the Ethernet port of a PC, without using a hub, the RTU port should be defined as an IP port (10/100 BT, Static, Ethernet LAN) with an IP address. The ports should be connected using an Ethernet crossover cable. IP Function

8-pin Connector (Plug 1)


TX-DATA +

1→

3←

TX-DATA -

2→

6←

RX-DATA +

3←

1→

N/A

4

7

N/A

5

8 A-8


IP Function



RX-DATA -

6←

2→

N/A

7

4

N/A

8

5

ACE3600 RTU Main CPU to Expansion Module Direct Connection To establish a direct link between an ACE3600 main frame CPU and an expansion module, the CPU’s ETH1 port must be configured as I/O Expansion Comm. Connect the CPU’s ETH1 port and the expansion module’s Exp. Eth1 port using an Ethernet crossover cable, with wiring as in ACE3600 RTU-to-PC Ethernet Port Direct Connection without Hub above.

ACE3600 RTU Main CPU to Expansion Module Connection via LAN Switch Note: The RJ45 connector head for this connection is standard. The numbering of the pins is according to the standard, as shown in the figure below. Pin 1-8 are right to left, as shown below. Therefore, any standard Ethernet cable may be used.

The ACE3600 RTU main CPU can be connected to an expansion module via one or two expansion LAN switches. The CPU’s ETH1 port should be configured as I/O Expansion Comm. For the connections below, use a standard Category 5E shielded (FTP) LAN cable (up to 50m.) •

ACE3600 RTU main CPU to expansion LAN switch connection or connection of the first LAN switch to the second, if such exists (for systems with I/O expansion only)

•

ACE3600 RTU expansion LAN switch to expansion module connection (for systems with I/O expansion only)

IP Function



TX-DATA +

1→

1←

A-9


IP Function



TX-DATA -

2→

2←

RX-DATA +

3←

3→

N/A

4←

4→

N/A

5←

5→

RX-DATA -

6←

6→

N/A

7←

7→

N/A

8←

8→

A-10

Appendix B: Remote STS Modem Setup Hayes ACCURA 144 + FAX 144, V2.20E Modem Type Model Version

Hayes ACCURA 144 + FAX 144 External 5611US 2.20E

Configuration (9600 Baud) at&v ACTIVE PROFILE: B0 E1 L1 M1 N0 Q0 T V1 W0 X4 Y0 &C1 &D0 &G0 &J0 &K0 &Q6 &R1 &S0 &T5 &X0 &Y0 S00:001 S01:000 S02:043 S03:013 S04:010 S05:008 S06:002 S07:050 S08:002 S09:006 S10:014 S11:095 S12:050 S18:000 S25:005 S26:001 S36:007 S37:009 S38:020 S44:020 S46:136 S48:007 S95:000 STORED PROFILE 0: B0 E1 L1 M1 N0 Q0 T V1 W0 X4 Y0 &C1 &D0 &G0 &J0 &K0 &Q6 &R1 &S0 &T5 &X0 S00:001 S02:043 S06:002 S07:050 S08:002 S09:006 S10:014 S11:095 S12:050 S18:000 S36:007 S37:009 S40:104 S41:192 S46:136 S95:000 STORED PROFILE 1: B1 E1 L1 M1 N1 Q0 T V1 W0 X4 Y0 &C1 &D2 &G0 &J0 &K3 &Q5 &R1 &S0 &T5 &X0 S00:000 S02:043 S06:002 S07:050 S08:002 S09:006 S10:014 S11:095 S12:050 S18:000 S36:007 S37:000 S40:104 S41:195 S46:138 S95:000 TELEPHONE NUMBERS: 0= 1= 2= 3=

Modem Settings AT&F0 ATB0 ATN0 AT&D0 AT&K0 ATS0=1 ATS37=9 AT&W0 AT&Y0

B-1

Appendix B: Remote STS Modem Setup

Command Summary (* indicates a change from the default) * *

B0 E1

*

L1 M1 N0

*

Q0 T V1 W0 X4 Y0 &C1 &D0

*

&G0 &J0 &K0 &Q# &R1 &S0 &T5 &X0 &Y0

ITU-T answer sequence Enable local echo (Must be set to E0 when modem is connected directly to the RTU as opposed to the PC.) Low volume Speaker ON until CONNECT Automode is disabled. The handshake will occur based on the value of S37. Display result codes Use tone dialing Verbal codes Report DTE speed Report all messages Turns off long space disconnect Normal CD operations (RLSD follows whatever the carrier is set to.) DTR override (This is necessary for the calling modem so that ESC doesn’t hang up.) Disable guard tone telephone jack, sets value for S21 Disables flow control not listed in help, don’t change Ignore RTS DSR override; always ON Prohibits Remote Digital Loopback Internal timing Resets with profile 0

B-2


S-Registers (* indicates a change from default) * *

S00=001 S037=009

sets the number of rings before modem answers Desired DCE Line Speed (This information is according to the standard Hayes Command Set. This was not in this modem’s documentation. Use with caution.) 0 Use Last AT Speed 1 Reserved (75) 2 Reserved (110) 3 300 4 Reserved (600) 5 1200 6 2400 7 4800 8 7200 9 9600 10 12000 11 14400 26 16800 12 19200 33 21600 29 24000 34 26400 15 28800

B-3


Hayes ACCURA 144 + FAX 144, V4.1 Modem Type Model Version

Hayes ACCURA 144 + FAX 144 External 5300AM 4.1

Configuration (9600 Baud) at&v ACTIVE PROFILE: DTE:9600 DCE: PARITY:NONE B16 B0 E1 L2 M1 N0 T Q0 V1 W0 X4 Y0 &A0 &B1 &C1 &D0 &G0 &K0 &L0 &Q5 &R0 &S0 &T4 &U0 &X0 &Y0 S00:001 S01:000 S02:043 S03:013 S04:010 S05:008 S06:002 S07:050 S08:002 S09:006 S10:014 S11:095 S12:050 S18:000 S25:005 S26:001 S30:000 S36:007 S37:009 S38:020 S43:000 S46:002 S48:007 S49:064 S50:220 S63:009 S82:128 S86:000 S95:000 S97:030 S108:001 S109:062 S110:002 S136:003 STORED PROFILE 0: B16 B0 E1 L2 M1 N0 T Q0 V1 W0 X4 Y0 &A0 &B1 &C1 &D0 &G0 &K0 &L0 &Q5 &R0 &S0 &T4 S00:001 S02:043 S06:002 S07:050 S08:002 S09:006 S10:014 S11:095 S12:050 S18:000 S25:005 S26:001 S30:000 S36:007 S37:009 S38:020 S46:002 S48:007 S63:009 S82:128 S95:000 S97:030 S108:001 S109:062 S110:002 S136:003 STORED PROFILE 1: B16 B1 E1 L2 M1 N1 P Q0 V1 W0 X4 Y0 &A0 &B1 &C1 &D2 &G0 &K3 &L0 &Q5 &R0 &S0 &T4 S00:000 S02:043 S06:002 S07:050 S08:002 S09:006 S10:014 S11:095 S12:050 S18:000 S25:005 S26:001 S30:000 S36:007 S37:000 S38:020 S46:002 S48:007 S63:009 S82:128 S95:000 S97:030 S108:001 S109:062 S110:002 S136:003 TELEPHONE NUMBERS: &Z0= &Z1= &Z2= &Z3= OK

Modem Settings AT&F0 ATB0 ATN0 ATT AT&C1 AT&D0 AT&K0 ATS0=1 ATS37=9 AT&W0 AT&Y0

B-4


B-5


Motorola OnlineSURFR 28.8 Modem Type Model Date Code:

Motorola OnlineSURFR External MODEMSURFR 28.8 EXT 3696

Configuration (9600 Baud) at&v ACTIVE PROFILE: B0 E1 L2 M1 Q0 V1 W0 X4 &B1 &C1 &D0 &G0 &L0 &P0 &Q0 &R1 &S0 &X0 &Y0 %A013 %C0 %G0 \A3 \C0 \G0 \J0 \K5 \N0 \Q0 \T000 \V1 \X0 -J0 "H0 "O032 S00:001 S01:000 S02:043 S03:013 S04:010 S05:008 S06:002 S07:060 S08:002 S09:006 S10:014 S11:095 S12:050 S18:000 S25:005 S26:001 S37:009 S72:000 STORED PROFILE 0: B0 E1 L2 M1 Q0 V1 W0 X4 &B1 &C1 &D0 &G0 &L0 &P0 &Q0 &R1 &S0 &X0 %A013 %C0 %G0 \A3 \C0 \G0 \J0 \K5 \N0 \Q0 \T000 \V1 \X0 -J0 "H0 "O032 S00:001 S02:043 S03:013 S04:010 S05:008 S06:002 S07:060 S08:002 S09:006 S10:014 S11:095 S12:050 S18:000 S25:005 S26:001 S37:009 S72:000 TELEPHONE NUMBERS: &Z0= &Z1= &Z2= &Z3=

Modem Settings AT&F0 ATB0 AT&D0 AT&R1 AT%C0 AT%G0 AT\N0 AT\Q0 AT\V1 AT-J0 AT”H0 ATS0=1 ATS37=9 AT&W0 AT&Y0

B-6



B0 E1

L2 M1 Q0 V1 W0 X4

*

*

* *

* * * * *

&B1 &C1 &D0

&G0 &L0 &P0 &Q0 &R1 &S0 &X0 &Y0 %A013 %C0 %G0 \A3 \C0 \G0 \J0 \K5 \N0 \Q0 \T000 \V1 \X0 -J0 “H0 “O032

ITU-T answer sequence Enable local echo (Must be set to E0 when modem is connected directly to the RTU as opposed to the PC.) Speaker volume medium Speaker OFF when carrier is present Response messages ON Response messages as words (Verbal codes) CONNECT response message with computer-to-modem speed CONNECT message as set by W and \V commands, wait for dial tone check for busy signal, not listed in manual (common use: Fixed serial port rate) DCD on while carrier is present DTR (Data Terminal Ready signal) ignored (This is necessary for the calling modem so that ESC doesn’t hangup) No guard tone not listed in manual 39/61 pulse make/break ratio (US) not listed in manual not listed in manual (common use: Modem ignores RTS) DSR (Data Set Ready) always ON not listed in manual (common use: Internal timing) Powerup with user option set #0 Set auto-reliable fallback character to n (n = ASCII 1-127) Compression disabled Disable auto fallforward / fallback Maximum block size of 256 characters Disable auto-reliable buffer Disable modem port flow control Modem-to-modem speed & computer-to-computer speeds are independent not listed in manual Normal mode Disable computer flow control Disable inactivity timer Enable protocol result code No XON/XOFF characters to remote modem Disable detection of type of V.42 error correction Disable V.42 bis data compression control not listed in manual

B-7



S00=001 S037=009

sets the number of rings before modem answers Desired DCE Line Speed

(This information is according to the standard Hayes Command Set. This was not in this modem’s documentation. Use with caution.) 0 Use Last AT Speed 1 Reserved (75) 2 Reserved (110) 3 300 4 Reserved (600) 5 1200 6 2400 7 4800 8 7200 9 9600 10 12000 11 14400 26 16800 12 19200 33 21600 29 24000 34 26400 15 28800

B-8


Motorola OnlineSURFR 33.6 Modem Type Model Date Code:

Motorola OnlineSURFR External MODEMSURFR 33.6 EXT 0597


Modem Settings AT&F0 ATB0 AT&D0 AT&R1 AT%C0 AT%G0 AT\N0 AT\Q0 AT\V1 AT-J0 AT”H0 ATS0=1 ATS37=9 AT&W0 AT&Y0

B-9


Motorola OnlineSURFR 56K Modem Type Model Date Code: Serial No.:

Motorola OnlineSURFR External MODEMSURFR 56K EXT 0598 90709647 (Sayreville staging)


Modem Settings AT&F0 Restore factory configuration 0 AT+MS=9,0,9600,9600 Modulation mode (9=V.32, 9600 or 4800), 0=forced, min speed=9600, max speed=9600 AT&D0 Modem ignores DTR ATE0 Turn off command echo AT&R1 CTS is always active AT&K0 Disable computer/modem flow control AT\N1 Normal speed buffered mode (no error correction) AT%C0 Disable data compression ATS0=1 Rings to autoanswer = 1 AT\V1 Connect messages displayed in single line format ATW2 Report modem-to-modem speed in error correction mode AT&W0 Store active profile in NVRAM profile 0 AT&Y0 Recall stored profile 0 upon power up

B-10


UDS V.3225 Modem Type Model Version

UDS V.3225 External V.3225 LCD MINI SA

Configuration (9600 Baud) at&v ACTIVE PROFILE S00:001 S01:000 S02:043 S03:013 S04:010 S05:008 S06:002 S07:030 S08:002 S09:006 S10:014 S12:050 S14:8AH S16:00H S18:000 S21:84H S22:46H S23:00H S25:005 S26:000 S27:08H S28:015 S29:000 S32:06H S34:00H S52:000 S53:00H S54:01H S57:00H S58:000 S59:005 S60:41H S61:1EH S62:000 S63:255 S67:005 S69:005 S70:001 S71:00H S72:00H S78:030 S79:035 OK

Modem Settings Instructions to load Factory Option Set #2 (Asynchronous Dial-up without MNP) (Settings are made from front panel of modem.)                     

[V.32 9600 TALK] [DIAL STORED NUMBER ?] [DISPLAY STATUS ?] [SELECT TEST ?] [MODIFY CONFIGURATION ?] [CHANGE MODEM PARAMETERS ?] [CHANGE MNP PARAMETERS ?] [CHANGE DTE PARAMETERS ?] [CHANGE TEST PARAMETERS ?] [CHANGE DIAL LINE PARAMETERS ?] [CHANGE SPEAKER OPERATION ?] [LOAD OR STORE OPTION SET ?] [LOAD FACTORY OPTION SET ?] [ARE YOU SURE ?] [LOAD FACTORY OPTION SET #1 ?] [LOAD FACTORY OPTION SET #2 ?] (Brief message will be displayed) [STORE PRESENT OPTIONS ?] [ARE YOU SURE ?] (Brief message will be displayed) [MODIFY CONFIGURATION ?]

B-11

Press NO Press NO Press NO Press NO Press YES Press NO Press NO Press NO Press NO Press NO Press NO Press YES Press YES Press YES Press NO Press YES Press YES Press YES Press TALK/DATA


Factory Option Set #2 (Asynchronous Dial-up without MNP) 

MODEM PARAMETERS DCE RATE = DTE RATE NORMAL ORIGINATE FAST TRAIN DISABLED AUTO RETRAIN ENABLED TRANSMIT CLOCK INTERNAL DIAL LINE JACK TYPE RJ11 (PERMISSIVE) LINE CURRENT DISCONNECT LONG ENABLED LONG SPACE DISCONNECT ENABLED V.22 GUARD TONE DISABLED



MNP PARAMETERS MNP PROTOCOL DISABLED * DTE SPEED = DCE SPEED * FLOW CONTROL DISABLED * XON/XOFF PASS THROUGH DISABLED DATA COM PRESSION ENABLED * MNP ACTIVITY TIMER OFF MNP BREAK CONTROL 0 *



DTE PARAMETERS ASYNC DATA DTE RATE = 9600 8 BIT NO PARITY AT COMMAND SET ENABLED IGNORES DTR DSR FORCED HIGH DCD FORCED HIGH CTS FORCED HIGH DTE FALLBACK DISABLED OPTIONS RETAINED AT DISCONNECT



TEST PARAMETERS BILATERAL ANALOG LOOP DISABLED BILATERAL DIGITAL LOOP DISABLED DTE LOCAL TEST DISABLED DTE REMOTE TEST DISABLED REMOTE COMMANDED TEST ENABLED TEST TIMEOUT OFF



DIAL/DBU PARAMETERS TONE DIAL AUTO DIAL #1 WAIT FOR DIAL TONE WAIT DELAY 2 SECONDS PAUSE DELAY 2 SECONDS CALL TIMEOUT 30 SECONDS ANSWER ON 1 RING B-12




SPEAKER OPTION VOLUME MEDIUM ON UNTIL CARRIER DETECT

* Indicates variation from factory option set #1 (Information taken directly from manual)

B-13


UDS V.3400 Modem Type Model Version

UDS V.3400 External

Configuration (19200 Baud) Modem Settings 

MODEM OPTIONS (Modify Configuration) LEASED LINE 4 - WIRE V.34 - MODULATION 19200 – DCE MAX. RATE DISABLED – DCE MIN. RATE V.34 RATE THRESH LOW BER. V.34 ASYM RATES DISABLED FORCED ANSWER NORMAL/NORMAL ORIGINATE V.32b FAST TRAIN DISABLED AUTO RETRAIN ENABLED SQ AUTO RATE DISABLED INTERNAL CLOCK DIAL LINE JACK RJ-11 DIAL TX LEVEL – 10dBm LEASE TX LEVEL 0 dBm LINE CURRENT DIS LONG MANUAL DIAL BACKUP LOOPBACK TIME 15 MIN.



PROTOCOL OPTIONS LAPM PROTOCOL DISABLED MNP PROTOCOL DISABLED BUFFER MODE DIRECT DTE FLOW CONTROL DISABLED DCE FLOW CONTROL DISABLED XON/OFF PASSTHRU DISABLED INACTIVITY TIMER OFF BREAK OPTION #0 V.42 FAST DETECT DISABLED



DTE OPTIONS ASYNC DATA DTE RATE = 19200 8 BIT CHAR SIZE NO PARITY ‘AT’ COMMAND SET DISABLED IGNORES DTR DSR IS NORMAL B-14


DCD IS NORMAL CTS FORCED HIGH DTE FALLBACK DISABLED OPTIONS RETAINED AT DISCONNECT 

TEST OPTIONS BILATERAL DIGITAL LOOP ENABLED DTE LOCAL TEST DISABLED DTE REMOTE TEST DISABLED REMOTE COMMANDED TEST ENABLED TEST TIMEOUT OFF



DIAL LINE OPTIONS TONE DIAL AUTO DIAL #1 WAIT FOR DIAL TONE WAIT DELAY 2 SECONDS PAUSE DELAY 2 SECONDS CALL TIMEOUT 60 SECONDS AUTO ANSWER ON 1 RING AUTO CALLBACK DISABLED



SPEAKER OPTION VOLUME MEDIUM CHANGE ON UNTIL CARRIER DETECT

B-15


USRobotics Sportster 14400 Fax Modem Type Model Version

USRobotics Sportster 14400 Fax External

Configuration (9600 Baud) ati4 USRobotics Sportster 14400 Fax Settings... B0 E1 F1 M1 Q0 V1 X4 Y0 BAUD=9600 PARITY=N WORDLEN=8 DIAL=HUNT ON HOOK &A1 &B1 &C1 &D0 &G0 &H0 &I0 &K0 &M0 &N6 &P0 &R1 &S0 &T5 &Y1 S00=001 S01=000 S02=043 S03=013 S04=010 S05=008 S06=002 S07=060 S08=002 S09=006 S10=007 S11=070 S12=050 S13=000 S14=000 S15=000 S16=000 S17=000 S18=000 S19=000 S20=000 S21=010 S22=017 S23=019 S24=000 S25=005 S26=000 S27=000 S28=008 S29=020 S30=000 S31=000 S32=000 S33=000 S34=006 S35=000 S36=014 S37=009 S38=000 S44=015 S51=000 LAST DIALED #: (IMPORTANT NOTE:

dip switch settings can overwrite internal parameters)

Modem Settings AT&F0 AT&A1 AT&D0 AT&H0 AT&K0 AT&N6 AT&R1 ATS0=1 ATS37=9 AT&W0 ATY0

B-16


Command Summary (* indicates a change from the default)

*

*

*

* * *

*

B0 E1

F1 M1 Q0 V1 X4 Y0 &A1 &B1 &C1 &D0

&G0 &H0 &I0 &K0 &M0 &N6

&P0 &R1 &S0 &T5 &Y1

ITU-T answer sequence Enable local echo (Must be set to E0 when modem is connected directly to the RTU as opposed to the PC.) Online local echo OFF Speaker ON until CONNECT Display result codes Verbal codes Report all messages Default is profile 0 setting in NVRAM ARQ result codes enabled Fixed serial port rate Normal CD operations DTR override (This is necessary for the calling modem so that ESC doesn’t hang up.) No guard tone, U.S. and Canada Flow control disabled Software flow control disabled Data Compression disabled Normal mode, error contron disabled 9600 bps (&N0=Variable rate; &N1=300 bps; &N2=1200 bps; &N3=2400 bps; &N4=4800; &N5=7200 bps; &N6=9600 bps; &N7=12,000 bps; &N8=14,400 bps; &N9=16,800 bps; &N10=19,200 bps; &N11=21,600 bps; &N12=24,000; &N13=26,400; &N14=28,800 bps) U.S./Canada ratio, 39%/61% Modem ignores RTS DSR override; always ON Prohibits Remote Digital Loopback Sets break handling to Nondestructive, expedited

B-17



S00=001 S037=009


B-18


USRobotics Sportster 28800 Fax Modem Type Model Version

USRobotics Sportster 28800 Fax External

Configuration (9600 Baud) Use the following dip switch settings on the back of the modem: 1. Down (Ignore DTR) 2. Up (Verbal result codes) 3. Down (display result codes) 4. Up (echo off line commands) 5. Up (auto ans first ring) 6. Up (CD normal) 7. Up (upload at powerup) 8. Down (smart mode)

(IMPORTANT NOTE:

dip switch settings can overwrite internal parameters)

Modem Settings AT&F0 AT&A1 (Enables ARQ codes) AT&D0 (DTR ignored) AT&H0 (Flow control disabled) AT&K0 (Data compression disabled) AT&N6 (Forces connection at 9600 baud or modem hangs up) AT&R1 (Modem ignores RTS) ATS0=1 (Answer on first ring) ATS37=9 (no effect) AT&W0 (store to NVRAM 0) ATY0 (defaults to profile 0 at power up)

B-19


Command Summary (* indicates a change from the default)

*

*

*

* * *

*

B0 E1

F1 M1 Q0 V1 X4 Y0 &A1 &B1 &C1 &D0

&G0 &H0 &I0 &K0 &M0 &N6

&P0 &R1 &S0 &T5 &Y1

ITU-T answer sequence Enable local echo (Must be set to E0 when modem is connected directly to the RTU as opposed to the PC.) Online local echo OFF Speaker ON until CONNECT Display result codes Verbal codes Report all messages Default is profile 0 setting in NVRAM ARQ result codes enabled Fixed serial port rate Normal CD operations DTR override (This is necessary for the calling modem so that ESC doesn’t hang up.) No guard tone, U.S. and Canada Flow control disabled Software flow control disabled Data Compression disabled Normal mode, error contron disabled 9600 bps (&N0=Variable rate; &N1=300 bps; &N2=1200 bps; &N3=2400 bps; &N4=4800; &N5=7200 bps; &N6=9600 bps; &N7=12,000 bps; &N8=14,400 bps; &N9=16,800 bps; &N10=19,200 bps; &N11=21,600 bps; &N12=24,000; &N13=26,400; &N14=28,800 bps) U.S./Canada ratio, 39%/61% Modem ignores RTS DSR override; always ON Prohibits Remote Digital Loopback Sets break handling to Nondestructive, expedited

B-20



S00=001 S037=009


B-21


USRobotics Sportster 56K Fax Modem Type Model Version

USRobotics Sportster 56K Fax External

Configuration (9600 Baud) Use the following dip switch settings on the back of the modem: 9. Down (Ignore DTR) 10. Up (Verbal result codes) 11. Down (display result codes) 12. Up (echo off line commands) 13. Up (auto ans first ring) 14. Up (CD normal) 15. Up (upload at powerup) 16. Down (smart mode)

Modem Settings AT&F0 AT&A1 (Enables ARQ codes) AT&D0 (DTR ignored) AT&H0 (Flow control disabled) AT&K0 (Data compression disabled) AT&N6 (Forces connection at 9600 baud or modem hangs up) AT&R1 (Modem ignores RTS) ATS0=1 (Answer on first ring) ATS37=9 (no effect) AT&W0 (store to NVRAM 0) ATY0 (defaults to profile 0 at power up)

B-22


Intel SatisFAXtion Modem/400e Modem Type Model Version

Intel SatisFAXtion Modem/400e External PCFM6501 UNKNOWN

ACTIVE PROFILE: B0 E1 L0 M1 T Q0 V1 X4 Y0 &C1 &D0 &G0 &L0 &P0 &Q0 &R0 &S0 &X0 &Y0 \A3 %A013 \C0 %C1 %E1 \G0 \J0 \K5 \N3 \Q0 \T00 \V2 \X0 -J1 "H3 "S0 "O250 S00:001 S01:000 S02:043 S03:013 S04:010 S05:008 S06:002 S07:060 S08:002 S09:006 S10:014 S11:070 S12:050 S18:000 S25:005 S26:001 S31:000 STORED PROFILE 0: B0 E1 L0 M1 T Q0 V1 X4 Y0 &C1 &D0 &G0 &L0 &P0 &Q0 &R0 &S0 &X0 \A3 %A013 \C0 %C1 %E1 \G0 \J0 \K5 \N3 \Q0 \T00 \V2 \X0 -J1 "H3 "S0 S00:001 S07:060 S11:070 S18:000 S23:027 S25:005 S26:001 S27:000 S31:000 STORED PROFILE 1: B1 E1 L2 M1 T Q0 V1 X4 Y0 &C1 &D2 &G0 &L0 &P0 &Q0 &R0 &S0 &X0 \A3 %A013 \C0 %C1 %E1 \G0 \J0 \K5 \N3 \Q3 \T00 \V2 \X0 -J1 "H3 "S0 S00:000 S07:060 S11:070 S18:000 S23:011 S25:005 S26:001 S27:064 S31:000 TELEPHONE NUMBERS: &Z0 &Z1 &Z2 &Z3

OK Modem Settings AT&F ATB0 ATT AT&C1 AT&D0 AT&K0 ATS0=1 AT&W0 AT&Y0

B-23



B0 E1

*

L1 M1 N0

*

Q0 T V1 W0 X4 Y0 &C1 &D0

*

&G0 &J0 &K0 &Q# &R1 &S0 &T5 &X0 &Y0

ITU-T answer sequence Enable local echo (Must be set to E0 when modem is connected directly to the RTU as opposed to the PC.) Low volume Speaker ON until CONNECT Automode is disabled. The handshake will occur based on the value of S37. Display result codes Use tone dialing Verbal codes Report DTE speed Report all messages Turns off long space disconnect Normal CD operations (RLSD follows whatever the carrier is set to.) DTR override (This is necessary for the calling modem so that ESC doesn’t hang up.) Disable guard tone telephone jack, sets value for S21 Disables flow control not listed in help, don’t change Ignore RTS DSR override; always ON Prohibits Remote Digital Loopback Internal timing Resets with profile 0

B-24



S00=001 S037=009


B-25


Multitech Leased Line Modem Modem Type Model

Multitech Leased Line Modem External MT2834 BA for the 2 wire leased line model; MT2834 BL for the 2/4 wire leased line model.

Version

Configuration (9600 Baud) Modem Settings AT&F // set to the factory default values AT$AB9600 // set the serial BAUD rate, the baud rate from the modem to the PC AT$BA0 // this allows speed conversion to be ON. This locks the serial port BAUD rate // of the modem and does not allow the modem to adjust its serial BAUD rate to // match the computer or adjust to the speed of the opposing modem AT&W0 // This saves the parameters that were set by writing them to memory ATl5 // this allows viewing the current parameters stored by the modem

B-26

Appendix C: PC Communication over via MotoTrbo To enable the STS PC to communicate via a MotoTrbo radio, follow the procedures below (for Windows XP only).

Installing the USB Driver for the Radio 1. Install the MotoTrbo Customer Programming Software (CPS) on the STS PC. Restart the PC. 2. Connect the MotoTrbo radio to the PC using a data cable. Power on the radio. 3. Using the CPS, check that you are able to communicate with the radio. 4. Exit the CPS. While the radio is connected to the PC, change the network settings as follows (recommended): 5. Do Start -> Settings -> Network Connection and locate the MotoTrbo radio (under LAN or high speed Internet). If it does not appear, check that you are connected and that the radio is powered on. 6. Press F5 (refresh). 7. Right-click on the radio connection and select Properties. 8. Uncheck all check boxes except for Internet Protocol TCP/IP. 9. Check the last two checkboxes: "Show icon in notification area when connected" and "Notify me hen this connection has limited or no connectivity". 10. Press OK. You will now see an icon of MotoTrbo radio in the system task bar (lower right). 11. Open Start-> Run -> CMD. 12. Enter ipconfig. You should see: Ethernet adapter MotoTrbo: Connection-specific IP Address. . . . . Subnet Mask . . . . Default Gateway . .

DNS . . . . . .

Suffix . . . . . . . . . . . .

. . . .

: : 192.168.10.2 : 255.255.255.0 : 192.168.10.1

13. Ping the radio IP address 192.168.10.1 and make sure it succeeds.

C-1

Appendix C: Transmitting via MotoTrbo

Programming the Radio The MotoTrbo radio is programmed using the CPS. For specific instructions, see the MotoTrbo - XPR4350, XPR4380, DM3400, XiR M8220, DGM4100 Radio Installation Kit section of the ACE3600 RTU Owner’s Manual. These instructions below assume that the settings are as follows: 1. CAI General settings of Radio ID connected to PC is 2. The Radio ID of a second radio connected to the RTU is 3. 2. Network / CAI Network address is 12 (default). 3. Network / Radio IP address is 192.168.10.1 (default).

Communicating over the Air via MotoTrbo Radio 1. In order to transmit via the radio, enter: route add -p 12.0.0.0 mask 255.255.255.0 192.168.10.1 metric 2 route add -p 13.0.0.0 mask 255.255.255.0 192.168.10.1 metric 3

Note: This is needed only once. The "-p" remembers the settings even if the radio is powered off, or the cable is disconnected. 2. To check that the connection is OK, ping as follows and make sure it succeeds. ping 12.0.0.2

(12 is the CAI network address, 2 is the Radio ID). 3. To check that the connection to the remote radio (ID=3) is OK, ping as follows and make sure it succeeds. ping 12.0.0.3 -w 5000

(12 is the CAI network address, 3 is the Radio ID, -w 5000 means wait five seconds for a reply.) 4. To check that the connection to the remote RTU (via remote radio ID=3) is OK, ping as follows and make sure it succeeds. ping 13.0.0.3 -w 5000

(13 because to access the RTU, you specify the network ID 12 plus 1, -w 10000 means wait five seconds for a reply.) 5. In order for the STS PC to communicate directly with the RTU via the above MotoTrbo radio, in the STS Communication Setup set the Local Site IP address to 13.0.0.3. Note: In order to download to other RTUs connected to MotoTrbo radios, it is recommended to change the Local Site IP address in STS Communication Setup to that of the remote RTU. This is because of MotoTrbo’s limited throughput.

C-2

ACE3600 STS Advanced Features

Recommend Documents